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PREFACE 



This document describes the purpose and architecture of the Overlay Loader within the environment of BPM orCP-V. 
It is assumed that the reader is familiar with the usage of BPM/CP-V Monitor services as well as the Sigma Standard 
Object Language (see the BPM/BTM/SM Reference Manual, 90 17 41). 



GLOSSARY 



CCI (Control Command Interpreter): a processor (brought 
into core by the Monitor) which reads the IIOAD card 
and records the information in an LOCCT Table. 

core image: that part of a load module which is laid into 
core at execution time. 

core library: for CP-V, a special collection of files under 
the :SYS account for association with FORTRAN 
programs. 

DCB (Device Control Block): a table for use by the Monitor 
in performing an I/O operation. 

DCB Name Table: a loader-built table which directs the 
Monitor to the location of a particular DCB within a 
program. 

declaration stack: a Loader stack which serves to keep track 
of the declarations made in a given ROM. 

DEFCOM: a processor which outputs a special type of load 
module. 

expression stack: for any segment, a collection of expres- 
sions defining DEFs and forward references and expres- 
sions whose values are to be placed in the segment's 
core image. 

extended memory mode: a mode in which the Loader builds 
core images and relocation dictionaries in page-sized 
records within a file on the RAD. 

HEAD: a key to one of the records of a load module file, 
the record containing basic size and source information. 

idB: a CCI-built table containing information from the BI 
device (when BI is specified on the LOAD card). 

idD: a file built by CCI on the basis of I MODIFY cards 
following the J LOAD card. 

idG: the file name the Loader uses to access information 
specified by the GO option. 

idL: the file name assigned to a load module if no name is 
specified via the LMN option. 

idX: the name of the intermediate file used during the ex- 
tended memory mode to build standard (i.e., nonpaged) 
core image and relocation dictionary records (BFM only). 



JIT (Job Information Table): a Monitor table of information 
pertinent to the job currently in execution. 

library: the term ascribed to two files, :LIB and :DIC, which 
are constructed by the Loader. 

load item: a string of bytes representing a "clause" in ob- 
ject language. 

load module: a keyed file which is output by the Loader 
(and several other processors). 

LOCCT (Load Control Command Table): a table which the 
Loader must access for its own control card input. 

object language: the language generated by assemblers and 
compilers to convey information to the Loader. 

PASS3: a processor which calls the Loader to form a load 
module. 

path: a collection of segments of a program which can re- 
side in core at the same time. 

REF/DEF Stack: a Loader-built stack for each segment whose 
entries contain values for control sections, external 
names (DEFs, REFs, SREFs), and forward references. 

relocation dictionary: a record constructed by the Loader 
which indicates how to relocate each word of a corres- 
ponding core image record. 

ROM (Relocatable Object Module): a type of input compo- 
nent to the Loader which was generated by an assembler 
or compiler. 

segment: a piece of a program which may be replaced in 
core by another piece of the program. 

stack path: the collection of REF/DEF or expression stacks 
belonging to the segments on a given path. 

system id: a job-oriented identification number determined 
by the Monitor and supplied to the Loader via the 
LOCCT Table. 

TCB (Task Control Block): a Loader-built table containing 
the user's temp stack and areas for system use. 

TREE: a collection of tables reflecting the overlay structure 
of a program. 



1.0 ENVIRONMENT 

1.1 INTRODUCTION 

The purpose of any loader is to translate and unite its input (ROMs and libraries) into such a form 
that the output (a load module) may be executed under the target operating system. Accordingly, 
the Overlay Loader performs those functions which might be expected of any loader operating 
under BPM or CP-V: 

a. Process ROMs producing continuous sections of data, procedure, and DCBs 
(or static data if BPM), insuring a page boundary for the three protection 
types (00, 01, 10, respectively). 

b. Satisfy REFs among the ROMs. 

c. Access "libraries" to satisfy PREFs. 

d. Build DCBs. 

e. Build a DCB Name Table for Monitor use. 

f. Build a TCB, 

The special characteristics of the Overlay Loader are identified as follows: 

a. Create Overlay Programs 

An overlay program is one which has only one piece (segment) resident in core 
permanently. The other segments are called by the M:SEGLD procedure and 
brought into core as needed. These segments may reside (at different times) in 
the same core area, thus reducing the amount of core required to house the 
entire program. 

Since, in general, a program may consist of three areas (one per protection type), 
each beginning on a page boundary, the Overlay Loader must have the ability to 
create the three trees, each beginning on a page boundary. 



b. Reference Loading 

If the user does not choose to maintain responsibility for calling the segments 
of an overlay program (by explicitly using M:SEGLD), he may direct the 

Loader to insert the M:SEGLD code into his program by specifying REF or BREF 
on the ILOAD card. This code is built, in the BREF mode, wherever there is 
a branch type instruction involving a REF to a higher segment. In the REF mode, 
it is built wherever there is any expression whatsoever involving a REF to a 
higher segment. 

c. Load Module Libraries 

It is desirable to maintain libraries of frequently used routines which are themselves 
already in load module form, since subsequent inclusion of a library module would 
be faster than processing the original ROM language. 

d. Relocatable Load Modules 

The Loader creates a relocation dictionary which allows subsequent placement of 
the load module into a core area other than the one at which it was originally 
biased. Relocation is accomplished via a BIAS option on the !RUN command for 
BPM. ( NOTE: CP-V does not allow a BIAS on the IRUNcard; hence forCP-V 
the only use of the relocation dictionary is in the case of merging a library load 
module into another program.) 

e. Dummy Sections 

The Loader has the ability to recognize dummy sections of the same name in 
various modules and to allocate on the basis of the largest one encountered. 
This feature is generally used in large FORTRAN programs which rely heavily 
on COMMON (COMMON is a form of dummy sectioning). 



1.2 SYSTEM INTERFACE AND GENERAL OPERATING CHARACTERISTICS 

1 . 2. 1 Loader Operation Under BPM or CP-V 

The Loader operates under BPM or CP-V and produces either BPM or CP-V load modules. These 
load modules are not interchangeable due to differences in the format of the HEAD record and 
in the allocation of the DCB area (see Section 3.2. 1). Neither are the Loaders themselves 
interchangeable. That is, the CP-V Loader will not operate under BPM and vice versa, due to 
differences in obtaining memory (see Section 2,4). An assembly parameter will select those 
areas of loader code which are unique to BPM or CP-V. The parameter is MODE. At assembly 
time, in each source module except the last, this parameter must be set to for BPM and 1 for 
CP-V. 

1.2.2 Loader Entry/Exit 

Loader entry/exit is via CCI or the SYSGEN PASS3 processor (as a result of ILOAD or 1PASS3), 
If the Loader is entered via CCI, the ILOAD and ITREE cards and (optionally) the BI device are 
read by CCI and packaged into tables (see Tables, Section 3. 1. 1) prior to entry. If entry is 
through PASS3, these tables are accessed from a previously existing file (created by the 1LOCCT 
processor) and presented to the Loader in the same form rhat CCI would have presented them. 
The Loader decides which return to execute (an M:EXIT to CCI or an M:LDTRC to PA5S3) on the 
basis of register or JIT input. Also, for CP-V, if the Loader is to exit to PASS3, it must first 
"release" all memory which it obtained ( via M:GP or M:GCP or M:GVP). 

1.2.3 What the System Does With the Loader's Output 

A !RUN command will cause the "Program Loader" (in BPM-PRGMLDR, in CP-V-FETCH) to 
access the load module file, modify and/or relocate it, lay it into core per the dictates of its 
HEAD and TREE records and transfer control to the START address (whereupon the program is 
"in execution"). Figure 1 shows the user program as it sits in core during execution. 



If the program is overlaid, at some point it will issue an MrSEGLD call. (This was part of the 
user's code or was inserted by the Loader per the REF/BREF option.) Since a copy of the TREl 
is always a permanent part of the root segment (protection type 01), the segment loader has all 
the information it needs to access the desired segment, deposit it in its destination, and record 
the fact that the segment is now in core (to avoid unnecessary reloading in the future). 

Branching between segments is the user's responsibility if he issued an explicit M:SEGLD. If 
REF or BREF is in effect, the branching is automated by the Loader-built table entry. 
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Figure 1. Load Module Layout at Run-Time 



2.0 GENERAL OPERATING CHARACTERISTICS 

2. 1 FUNCTIONAL OVERVIEW 

2. 1.1 Loader Terminology 

At this point, it might be well to review some fundamentals of the object language and 

define some terminology relative to the Loader. 

a. Declaration Numbers 

Within a given ROM, all control sections, DEFs, PREFs, SREFs are declared; that is 
to say, each is assigned a "declaration number". (The ROM assigns declaration 
numbers consecutively. ) In an expression which involves any of these items, the 
ROM refers to them via their declaration number. The Loader, therefore, must 
remember these numbers; it does so by building a declaration stack as the numbers 
are encountered within the module. (The stack is destroyed at module end since it 
has no meaning for the next module. ) An entry in the declaration stack is simply a 
pointer to the proper entry in the segment's REF/DEF stack (which will eventually 
contain the complete story about that declaration). 

b. Dummy Sections 

Within a ROM, a dummy control section is treated as both a DEF and a control 
section. In particular, the ROM must first declare the dummy section's name (the 
label that is to be associated with the first location of the section) as an ordinary 
external definition. Subsequently, the ROM declares the dummy section itself as 
a control section (via 'Declare Dummy Section'). This declaration refers to the 
previously declared label, thereby associating the name with the dummy control 
section. 



c. Expressions 

The value of a DEF, Origin, Start or forward reference is given to the Loader from the 
ROM via an expression. Load items to be placed in the core image also involve expres- 
sions. An expression consists of operators (control bytes) which operate on constants, 
declarations, and forward reference numbers. Thus, an expression might say "add the 
value of declaration 5 with the constant X'10" ". When the Loader wants to calculate 
the result of ("evaluate") this expression, it first looks in the fifth entry of the declaration 
stack to get a pointer to the proper REF/DEF stack entry. Next it adds the value word of 
that REF/DEF entry to the expression accumulator and then adds the value X'10' to rhe 
expression accumulator. 

d. Forward Reference Numbers 

Within a ROM we will encounter expressions involving forward references. These are 
referred to via random numbers. Therefore, the Loader must keep track of them in a 
similar way that it keeps track of declaration numbers. This is done by creating an entry 
in the REF/DEF stack containing the reference number. When a forward reference number 
is encountered in an expression, the Loader searches the REF/DEF stack for a match. If 
none is found, a new entry is created. Since the numbers are meaningless for the next 
module, the Loader "releases" them at module end. 

Forward references are of two types: those which can be resolved by module end or sooner, 
and those which cannot be so resolved. The latter type consists of forward references 
whose defining expressions contain REFs or DSECTs. When the expression to define the 
forward reference is encountered, it will indicate which of the above was meant (define 
forward reference (DFREF) or define forward reference and hold (DFREFH)). A DFREF 
expression implies that the corresponding forward number is now closed and invalid; 



a new expression involving that number refers to a new forward reference. The Loader 
must mark its REF/DEF entry as such ("release" it). On the other hand, a DFREFH expre 
sion implies that the number may occur within another expression. Therefore, it is still 
valid and cannot be released until module end. Notice that the number is always released 
at module end, even though the forward reference itself may not be resolved yet. 



e. Files, Segments, and Paths 

A segment is made up of files (ROMs or load modules) and is a piece of the target load 
module. A segment may be overlaid by another segment. A path of an overlay structure 
is a set of segments which reside in core at the same time. The root is the segment which 
is always in core. In Figure 2, there are three paths: S0-S1-S3, S0-S1-S4, and S0-S2. 
Given a segment we may speak of its back-link, forward-link, and overlay-link. (The 
forward-link is also called the "sub! ink"') 

Referring again to Figure 2: 
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f. Loader Stacks 

The Loader forms three stacks: the declaration stack, REF/DEF stack, and expression stack. 
The declaration stack is created and destroyed for each ROM. An entry in the declaration 
stack is simply a pointer to that entry in the REF/DEF stack which describes the declaration]. 
The REF/DEF stack is really a misnomer since it includes an entry for every declaration 
(control section, DEF, REF, SREF) as well as for forward references. 

The expression stack contains defining expressions for DEFs and forward references, as 

well as expressions whose value is to be added to a word in the core image itself (core 

expressions). 

The components of an expression are operators (control bytes) acting on declaration 

numbers, forward reference numbers, and constants. The value (result of performing the 
operations, e.g., add value of declaration, add constant, etc.) is either placed in the 
VALUE word of the REF/DEF stack or in the core image if it is a core expression. 
The Loader creates a REF/DEF and expression stack for each segment. These stacks are 
created along a path. The Loader's stack area will develop in the same way that the seg- 
ments are overlaid. In Figure 2, if we are working on S4, then the stacks for SO and SI 
and S4 are in core. If stack S4 is in core, stack S3 will not be, since they are on 
different paths. (This implies, incidentally, that if one segment is to communicate with 
another via REFs and DEFs, they must lie on the same path.) We refer to a "stack path" 
as the set of stacks belonging to a given path. 



2.1.2 The First Pass 



The first pass gathers all information relative to the sizes of major pieces of the load module 
(i.e., the size of each protection type per segment and the stack sizes). Additionally, the first 
pass provides the second pass with an efficient means of developing the core image by constructing 
the REF/DEF and expression stacks. As it scans each input component (ROM or load module), 



Pass One examines only that information necessary to accomplish these two functions; viz., 
size computation and stack construction. Any information not relevant to these functions 
is ignored until Pass Two. 

If the component is a ROM, the sizes are to be found in the "declare control section" 
load items. Pass One accumulates each control section size in the appropriate protection 
type of the TREE. A REF/DEF entry is also built for each "declare control section" load 
item, as well as for load items which declare names as forward references. (For each 
name declaration, either a new entry is added to the REF/DEF stack or an old one is 
modified.) Expression stack entries result from load items which define external DEFs or 
forward references. (When a new entry is made in either the REF/DEF or expression stack, 
the size of that stack is updated in the TREE. ) All load items dealing with the content of 
the core image (e.g., "load relocatable") are ignored. 

If the component is a load module, the HEAD and TREE records contain the sizes of the 
core image and the stacks. These are added to the TREE. The load module's stacks are 
then merged with the ones being constructed. The core image and relocation dictionary 
records are ignored until Pass Two. 

At the end of processing each segment's explicit element files, the REF/DEF stack is 
scanned for a I I PREFs except those having names starting with M: or F: (for which the 
Loader will build DCBs). For each PREF found, Pass One searches those libraries specified 
on the ! LOAD card for a load module which will satisfy the PREF. If it finds one, the load 
module's name is added to the list of input files (ROM Tables), the size is recorded in the 
TREE and its stacks are merged with the ones being built. 
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The sequence of processing the overlay structure is from the root segment outward, as shown in 
Figure 2. Figure 3 shows the general flow during Pass One. 

S3 





SI 


€ 


S4 




© 


S2 


& 


© 








so 





Figure 2. Segment Processing Sequence, Pass One 



a. 



b. 



At the end of the first pass we have: 

sizes of the segments per protection type, including the sizes of modules obtained 
from the library. These sizes are in the Tree Tables. 

a REF/DEF and expression stack for each segment written to the RAD. The stacks 
are structurally complete. They include the merged library stacks. The value and 
resolution for each REF/DEF entry is not determined until the second pass. 

defining expressions for DEFs and FREFs in the appropriate expression stacks. 
The expression stacks also include expression stacks from library load modules. 

sizes for the REF/DEF and expression stacks in the Tree Tables. 



c. 



d. 



e. 



ROM Tables augmented by the names of library load modules pulled in as a 
result of satisfying PREFs. 
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Enter \ 

Pass One J 

1NIT1 " 

Allocate work space for 
PASS1. 



STANDARD 



PASS1 



Set Current Segment 
(CSEG) to ROOT. 



LP1 or ADLDMD " 



Process input files 
(ROMs or load mod- 
ules). Building stacks 
and accumulating sizes. 



SAT RE F 



Satisfy any PREFs except 
M: or F: from Libraries. 



OPL2 




yes 



Write CSEGs Expr. 
Stack, adjust stack 
pointer to remove 
this stack. 



Flag DCBs to be built 
by Loader. 



yes 



( exit N 

\ ^ PASSl J 




Write CSEGs REF/DEF 
Stack, adjust stack 
pointer to remove this 
stack. 




yes 



Set CSEG to 
Back-Link. 



Set CSEG to Sublink. 



Set CSEG to Overlay 

Link. 



Figure 3. The First Pass - General Flow 
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2.1.3 The Second Pass 

This pass develops the actual core images and relocation dictionaries and writes the load module 
to the RAD. 

Based on the sizes known from PASS1, core is partitioned into the stack area and buffers for the 
core images and relocation dictionaries. If this partitioning is not possible, Pass Two goes 
into "extended memory mode", meaning that the core images and dictionaries will be developed 
within an intermediate RAD file, page by page. 



The expression and REF/DEF stacks for an entire path are brought into core and, from the size 
and protection type of every control section, locations are assigned to all of the sections (the 
control sections are "allocated") along this path. 

After evaluating and defining all possible DEFs and FREFs, Pass Two is now in a position to 
reread the input files (proceeding backwards along a path). As it reads, it places data in the 
core and relocation buffers (or into the extended memory mode file, as the case may be) as per 
the dictates of the load items. When a segment is complete, its REF/DEF stack, expression stack 
core images, and relocation dictionaries are written out (unless we are in extended memory mode, 
in which case processing of the paged core image and relocation dictionary records 
is deferred until the root segment has been constructed). 

The sequence of forming the core images for an overlay structure proceeds from the sublinks 
back toward the root, but, as mentioned, allocation occurs forward along a path (see 
Figure 4). 
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© 
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© 

SI 


© 
S3 


S4 © 


© 

S2 




SO 







Sequence of Core Image Allocation 
Per Segment 



Sequence of Forming Core Image 
Per Segment 



Figure 4. Segment Processing Sequence, Pass Two 

Special attention comes into play when we reach the root segment at the end of the second pass. 
If extended memory mode is in effect, the load module must be reconstructed from the page rec- 
ords of the extended memory mode file which were created during the formation of the core image 
In any case, the TCB and DCBs are built, the HEAD and TREE records are written, necessary 
modifications per ! MODIFY cards are made, the severity level is printed, and the Loader 
returns control to CCI or PASS3. 

Figure 5 shows the general flow of Pass Two. 



14 



INIT2 



r Enter the A 





Partition core. Set 
XMEM if necessary. 




NEXTSEG3 v 




Set current segment 
(CSEG1) to root. 


G\ 






VJ • 
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11 






Read CSEG's stacks. 






ALLOCATE " 






Assign locations to all 
control sections. 












X... 


INK?^ 


Set CSEG 


to sum ink. 




yesXr DL 



EVEXSQZ " 



Evaluate path's 
expressions. 



r- 



k— 




Squeeze root's EXPR 
stack. 



Is there enough room 
.* for the stacks and 1-2 ^ 
~yes\ pages for extended ^ 
memory buffers? 



© 




C Abort J 



Figure 5. The Second Pass — General Flow 
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Write core images and 
relocation dictionaries. 



Set CSEG to overlay 
link. 



© 



LOADSEG T 

Process input files (ROMs 
or load modules) forming 
core images and reloca- 
tion dictionaries within 
buffers or XMEM file. 



Write CSEG's REF/DEF 
and EXPR stacks. 



no 




yes 



Pull CSEG's stacks, and 
location counters (DLOC, 
PLOC, and SLOC) back 
to the beginning of this 
segment. 




Reconstruct load module 
from XMEM file or clean 
up paged load module. 
Write load module. 



( ^ ^ 
V PASS2 J 



Set CSEG to Back Link. 



(Exit the A 
2nd pass.) 

Figure 5. The Second Pass — General Flow (cont.) 
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2.1.4 Advantages of a Two-Pass Loader 

a. The primary advantage is accorded to FORTRAN programs that use Blank COMMON. 

A two-pass loader has the ability to discover the largest dummy section of the same name 
(dummy sections are intrinsically externally defined) and to allocate accordingly. This 
would be, if not impossible, an extremely difficult matter for a one-pass loader. 

b. A one-pass loader has difficulty with overlaid load modules having more than one 
protection type. The problem arises in determining how many pages of memory should be 
allocated for the 00 protection type before allocating for the 01 protection type. A two- 
pass loader can compute, in its first pass, the size each protection type requires and can 
allocate memory accordingly for the second pass. 

2.2 STRUCTURE: THE MAJOR PIECES 

The Overlay Loader is a two-pass loader; that is, the ROMs and load modules from which the 
target load module is constructed are read two distinct times. The Loader is composed of eleven 
ROMs. These ROMs may be grouped according to their usage in the first or second pass. 



When Used 


File Name 


Entry Points 




Catalog No, 


Throughout 


LDR 


LOADER 




704724 


both passes 










First Pass 


INI 


INIT1 




704725 




PS1 


PASS1 




704726 


Second Pass 


IN2 


INIT2 




704727 




PS2 


PASS2 




704728 




ALLL 


ALLOCATE 




704729 




SQZ 


EVEXSQZ,! 


5QUEEZ 


706446 




EVL 


LOADSEG, 


EVEXPRS 


704730 




WRT 


WRITESEG 




704731 




FIN 


FINISH 




706258 




MOD 


MODIFY 




705396 
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2.2.1 LDR 

This ROM is a collection of frequently used subroutines, temp space, variable data, 
DCBs and a driver which contains the start address (LOADER) and which subsequently 
BALs to the first and second passes and exits. 

The LDR module contains the Loader's only DATA area (one page). This area is 
composed of two parts: a temp stack (pointer in RO) and a collection of variable data 
(stack pointer, doubleword buffer pointers, location counters, etc. ). See 
Appendix B for a description of the use of the variable data cells in the loader's 
STUFF stack. 

Figure 6 illustrates the format of this area. 
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DECLSTK-j^> pedaration stack pointer 

Doubleword 

RFDFSTK-OI REF/DEF Stack Pointer 

EXPRSTK~[> 



Doubleword 



Expression Stack Pointer 
Doubleword 



Declaration Base 



REF/DEF Base 



Expression Base 



RO points here 1 

Temp stack begins ~ 
here 



Miscellaneous Variable data such 

as OPEN lists, card and 

printer buffers, buffer pointers, etc. 



Lo_adej; , s_ temp_stack_ Pojnter 



Doubleword 



DECLSTK+X'100 L 



declstk+xmff: *i 



A couple of subroutines placed 
here to fill up the Loader's 
Data page. 



Figure 6. Loader's DATA (00) Area (Within LDR) 
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2.2.2 The First Pass 



INI - entry/exit from LDR. 

allocates the work space for PS 1 . 
reads the LOCCT, ROM, TREE Tables, 
reads and processes the ASSIGN record. 

PS1 - entry/exit from LDR. 

reads and processes ROMs and load modules, collecting the information 
necessary to ascertain sizes of control sections and maximum stacks, 
satisfies PREFs from libraries, 
writes out interim stacks. 



2.2.3 The Second Pass 
IN2 - 



PS2 



ALLL - 



SQZ - 



EVL - 



WRT 



FIN 



MOD - 



entry/exit from LDR. 

allocates the work space for the second pass, determining if extended 

memory mode is necessary. 

entry /exit from LDR. 
a driver for the second pass, 
calls ALLL, SQZ, EVL, and WRT. 
reads current segment's stacks. 

entry /exit from PS2. 

assigns locations to all control sections. 

prints load module allocation summary. 

entry/exit from PS2 at two entry points, EVEXSQZ 

and SQUEEZ. 

evaluates expressions and squeezes root's expression stack. 

has two entry pints, EVEXPRS and LOADS EG, both from PS2. 
evaluates expressions from PASS1 and core expressions from load modules, 
forms core image and relocation dictionary going through extended 
memory mode logic, 
builds reference loading table. 

entry/exit from PS2. 

creates TCB and DCBs, and the DCB Name Table. 

concatenates the pages of the extended memory mode file for a standard 

load module. 

cleans up the paged core image records for a paged load module. 

writes the load module to the file. 

entry/exit from LDR. 
updates and prints severity level, 
reads idD and calls MOD. 
generates load map. 

entry/exit from FIN. 

performs the modifications per IMODIFY cards which followed the 

!LOAD. 
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2.2.4 Forming the Loader 

If the Loader is overlaid, it bears the following TREE structure for BPM: 

1TREE LDR-(IN1,PS1,IN2,PS2-(ALLL, SQZ, EVL, WRT), FIN-MOD) 
INI 



2.3 



LDR 





PS1 




IN2 






PS2 


ALLL 






SQZ 




FIN-MOD 


EVL ' 




WRT 







The CP-V Loader is overlaid according to the following TREE structure: 

!TREE LDR-PS2-: J0-(IN1, PS1, IN2, ALLL, SQZ, EV L, WRT, FIN -MOD) 

INI 





PS1 




IN2 


LDR-PS2-:J0 


ALLL 






SQZ 




EVL 




WRT 




FIN-MOD 



The tree structure is such for the CP-V Loader because, as a shared processor, the Loader 
is allowed only one level of overlay. Note also that the file :J0 (in :SYS) must be listed 
as the last element file when forming the CP-V version: 

'LOAD (LMN, LOADER), (NOTCB), (NOSYSLIB), (SL,F), ; 
! (EF,(LDR) / (INl),(PSl),(IN2) / (PS2),(ALLL),(SQZ),(EVL),(WRT),(FIN),(MOD), 
(:J0,:SYS)) 

The debug version should be loaded without specifying NOTCB. See Section 2.5. 
HOW THE LOADER USES MEMORY 



2.3.1 Partitioning Core for the First Pass 

Recall that the first pass, after it has read the LOCCT, ROM, and TREE tables, constructs the 
REF/DEF and expression stacks. (The declaration stack is volatile for each ROM.) Accordingly, 
the partition concerns itself with only these areas. (Partitioning for the first pass is done by INI.) 
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LOADER 
DATA 
__0 page)_ 

LOADER 
PROCEDURE 



LOCCT 
£>MJqbles 



aoies 



Declaration 
Stack 



REF/DEF 

STACK 

Growth 



^.Background Lower Limit 
' See Figure 6 for Detail. 



.«. .First Available Page 

J Initially 64 Words, expanded up if necessary. 
i-REF/DEF Begins Here 



>^ 



EXPRESSION 
STACK 
Growth 



EXPRESSION Stack Begins Here 
^ TOPOMEM 



^ 



Figure 7. How the Loader Uses Memory: Pass One 

If the REF/DEF and EXPRESSION Stacks meet during Pass One, processing is discontinued 
(JOB aborts). 

2.3.2 Partitioning Core for the Second Pass 

The second pass is concerned with developing the core images and relocation dictionaries (unless 
ABS was specified, in which case there are no relocation dictionaries). Buffers are needed to 
house these. 

There must also be room to hold the REF/DEF and EXPRESSION stacks for the largest path. The 
size of the REF/DEF stack is known from PASS!, but the expression stack can grow (due to 
unevaluatable core expressions). Maximum declaration stack size was also retained in PASS1. 
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There are two partitioning schemes: nonextended memory mode and extended memory mode. 
IN2 (which performs the partitioning) will select the former, if space permits. 

a. Nonextended Memory Mode (Fig. 8) 

Two buffers are reserved for each protection type; one for the core image and one for the 
relocation dictionary. Such buffers are reserved for the root and for the current segment. 
Hence, in a full-blown relocatable TREE, there would be 12 buffers. (The reason for 
the double buffers is to permit a higher segment with load items in a DSECT belonging 
to the root to store those items into the root.) 

Since the expression stack can grow, the buffer allocation begins from TOPOMEM 
down. (Notice that the expression stack is growing in the opposite direction than it did 
in the first pass. ) 
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Current Segment 
Relocation Dictionari 
(Room allowed for 
largest of each type.) 
Current Segment 
Core Images 
(Room allowed for 
largest of each type.) 



Root Relocation 
Dictionaries 



( 



Root Core 
Images 



Loader's 
DATA Area 

Loader's 

PROCEDURE 

Area 



LOCCT 
ROM Tables 
TREE Tables 



Declaration 
Stack 



REF/DEF 
Stack 



I 



EXPRESSION 
Stack 

(can grow due 
to core expres- 
sions) 



00 



01 



10' 



«*■ 



-*- 



Background Lower Limit 



First Available Page 



Room allowed for the largest 
REF/DEF stack path. 



4 CREL00 

+ CREL01 

+ CREL10 

* CSEG00 



JQ 

IRI 



SEG 
REL 1 



B 



are byte pointers to 
the buffers. They 
are kept in the 
Loader's DATA Area, 



.CSEG01 
-CSEG10 

RREL00 
-RRELOl 
RREL10 
RSEG00 

RSEG01 
RSEG10 



-TOPOMEM 



* 

ForCP-V, these buffers can grow due to rounding to prevent DCBs from overlapping page bound- 
aries. If this occurs, all buffer pointers are shifted down accordingly. See Section 5.3. 

Figure 8. How the Loader Uses Memory: Pass Two - Nonextended Memory Mode 
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b. Extended Memory Mode (Figures 9a and 9b) 

If the above partition is not possible, IN2 enters extended memory mode which 
consists of replacing the 12 buffers with page buffers (one if ABS is specified, two 
if not) at TOPOMEM down. All segments, including the root, are built within 
these buffers. The EVL module uses these buffers to construct page records of the 
core images and relocation dictionaries. The file used to develop these records is 
either a temporary (idX) file (for a standard load module) or the load module file 
itself (for a paged load module). Only one page buffer is required in the latter 
case since a paged load module is forced ABS. Figure 9a illustrates the use of 
memory during the construction of the page records. 

If a standard load module is to be constructed in extended memory, memory is 
partitioned differently at the end of the second pass (in the module WRT), Six 
buffers (or three if ABS) are used to concatenate the page records, one segment 
at a time. Figure 9b illustrates memory usage during the concatenation (some- 
times called "put-together" phase) of extended memory mode. 

The above partition is not required for the paged load module; instead, room is 
needed only for those core image records belonging to the root which are to 
contain loader-built tables. These records are read in successive order above 
DECLBAS according to protection type. 
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1 page 
1 page 



Loader's 
DATA Area 



Loader's 
PROCEDURE Area 



LOCCT 
ROM Tables 
TREE Tables 



Declaration 
Stack 



REF/DEF 
stack 



EXPRESSION 
Stack 

(Can grow due to 
core expressions. ) 



I 



Relocation 
Dictionary 



Control 
Sections 



■Background Lower Limit 



-First Available Page 



' Room allocated for the longest 
1 REF/DEF stack path. 



Establish this page if not ABS 



^lOPOMEM 



In extended memory mode, it can diminish as a result of SQUEEZ processing. 

Figure 9a. How the Loader Uses Memory: Pass Two —Extended 
Memory Mode, Construction of Core Image Records 
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Loader's DATA 
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Loader's PROCEDURE 
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Dictionary 
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Core 

Image 
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00 
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00 
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T OPOMEM 



Figure 9b. How the Loader Uses Memory: Pass Two - Extended 
Memory Mode, Concatenation of Core Image Records 
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2.4 HOW THE LOADER OBTAINS MEMORY 

2.4.1 Loader Running Under BPM 

INI simply does a M:GP requesting the maximum (256) number of pages. 

2.4.2 Loader Running Under CP-V 

Since memory must be obtained from both ends of the dynamic page area, and since CP-V 
restricts the number of pages obtained, the above BPM technique does not suffice. INI 
initially gets four pages via M:GP. It then takes memory trap control (M.-TRAP) such that 
"demand paging" is in effect. That is, whenever a memory violation occurs due to access of 
an unauthorized page, the Loader's TRAP routine (in the LDR module) is entered. TRAP com- 
putes the virtual page address requested and obtains the page via M:GVP. 

2.5 MAINTAINING THE LOADER, DEBUG MODE 

The Loader program, as a processor, cannot be executed as a user's program since it does not 
read its own control card. However, a special version of the Loader (called the "debug 
version") can run as a user's program, thus making Loader maintenance and modification an 
easier task. The debug version of the Loader is obtained by assembling LDR, INI, and PS2 with 
the assembly parameter DEBUG EQU'd to 1. This causes code to be assembled which will read 
the LOCCT, ROM, and Tree Tables from a file (created by the LOCCT processor). It also 
causes the M:BIandM:DO DCBs to be built for reading the LOCCT and for handling ISNAPs, 
IMODIFYs, and IPMDs. A debug Loader can be assembled for either CP-V or BPM, as 
determined by the parameter MODE. 

Example: 

1 I ASSIGN M:BI,(FILE,LOCCTTEST) 

2 IRUN (LMN,DELOAD),(XSL,F) 

3 IMODIFY 

!SNAPMESSAGE,MSG,(DECLSTK,DECLSTK+100),(+E200,+E600) 

n !PMD (00) 
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Card 1. The file must have been created by the LOCCT processor 

(see BPM Reference Manual, 90 09 54). 

Card 2. The Loader (DELOAD in this example) must have been 

formed with LDR, INI, and PS2 assembled in the DEBUG 
EQU 1 mode. 

Card 3-n MODIFYs and debug commands. 

In this mode the Loader may also be executed from the terminal under the RUN 
subsystem for BPM or as any other user program with or without DELTA for CP-V. 
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3.0 INPUT, OUTPUT, LOADER-GENERATED TABLES 

3. 1 INPUT 

3.1.1 LOCCT, ROM, Tree Tables 



Based on the ILOAD and ! TREE cards, three related and contiguous tables are presented to the 
Loader upon entry: the Load Control Command Table (LOCCT), the Tree Table, and the ROM 
Table. If BPM is operating, the tables reside on sector 36 of the absolute area of the disk. 
Total size is contained in R6 upon entry to the Loader. If CP-V is operating, the tables are left 
in core preceded by a word containing the size. A pointer to this area is in word JB:BCP of the 
JIT. 

In either case, the Loader moves these tables into its first dynamic page (M:GP) during 
initialization. 
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Size of the three tables to fol low 



(CP-Vonly) 



1 2 3 4 5 6 7 8 9 10 11 12 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31* 



LOCCT 



. r— 

SL P O 



N M 



J I 



F E 



Displacement from LOCCT to ROMT 



Displacement from LOCCT to TREET 



SYSid 



REF or BREF count (default = 0) 



LOAD BIAS (WA) 



Number of Execute Accounts (default = 1) 



FCOM Size 



ERSTACK Size (default , X'A') 



TSS Size (default = X'40') 



Number of READ accounts (default = 1) 



FCOM (DA) *** 



ERTABLE Size (default , X'A') 



Number of UNSAT accounts 
(default = if NOSYSLIB; = 1 (:SYS) if not) 



Number of WRITE accounts (default = 1) 



Load Module Name, TEXTC followed by blanks, (default = three characters SYSid L) 



User Account Number 



Load Module Password (default =0,0) 



EXPIRE date; 'mmddWyy' or 'NEVER' (BPM) 0,0 (CP-V) 



Library Password i.e., (PERM, LIB, password) (default = 0, 0) 



8 max, 



z 



READ Account Numbers - 2 words per account *, (default ='ALLfcfWW) 






WRITE Account Numbers - 2 words per account *, (default = 'NONEkflW) 



y 



8 max. 



$ 



EXECUTE Account Numbers - 2 words per acct. *, (default = 'NONEkftW) 



1 max, 



z 



EXECUTE Vehicle - 3 words per vehicle, (default = FETCHWMW) 



P 



Total Number of words in TREE Tables 



TREET ► 



jZ TREE Tables - 1 Table per Segment - 1 1 words per table ( See Figure 12 for format) 



ROMT » 



z 



ROM Tables - 1 Table per ROM - 7 words per table (See Figure 1 1 for format) 



Z 



z 



8 max. X UNSAT Account Numbers and Passwords - 4 words per (acct *, pass), (default password = 0,0) Z 



z 



z 



z 



z 



Figure 10. Loader Control Command Table (LOCCT) 



/ 
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Footnotes for Figure 10: 





A 


= 




r UDEF specified 






B 


= 




, N OS YS LIB specified 






C 


= 




, REF specified 






D 


= 




, PERM specified 






E 


= 




, LIB specified 






F 


= 




, M10 specified 






G 


= 




, Ml 00 specified 






H 


= 




, FCOM specified 






I 


= 




, ABS specified 






J 


= 




Assigns Read 






K 


= 




, GO specified 






L 


= 




, BI specified 






M 


= 




, CSEC1 specified 






N 


= 




, NOTCB specified 






O 


= 




XMEM in effect (set by the Loader in IN 2), 


or PAGE specified 




P 


= 




r LDEF specified 






Q 


= 




BREF specified 






R 


= 




r EF specified 






S 


= 




, CORE LIB specified 






T 


= 




, RDEF specified 




bits 10 - 


11 




o' 


= no map 




(U-V) 






2 
3 


= map by NAME 
= map by VALUE 
= map by NAME and VALUE 






X 


= 


•/ 


, Execute Vehicle specified 






Y 


= 


■ j 


, MAPONLY specified 





SL = Severity Level (default = 4) 



** BPM-CP-V differences in the LOCCT Tables: 



Word 



BPM 



CP-V 



LOAD BIAS field, default = 



LOAD BIAS, Default = background 
lower limit WA 



Background lower limit 



Number of Execute Accounts, 
Default = 1 



Passed to the Loader in Register 
D4 (D4) = FCOM size 
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ROM Tables 

The ROM Tables contain an entry for every input file (ROM or load module). 
Below is an overall picture for M segments (SO, SI, . . . SM). Each box is a severe 
word entry. 



SO 



RJO" 



BE 



SI 



Jffi 



J35 



SM 



m 



H£ 



BSl 



ROM Table Entry 



TEXTC of ROM name (EF name, 


or 


SYSid 


B 




for BI, 


or SYSid G for GO). 

















X L 


00 T 





Account number 




(default = current 


ace 


t') 








Password 












(default = 0, 0) 









X = 1, if this is not the last ROM file in the segment. 

L,T are initially but set by the Loader. 

L = 1, if file came from a library. 

T = 1, if file is on labeled tape. 

Figure 11. ROM Tables 
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Tree Tables 



Overall oicrure for M segments (SO, . . . SM) 



TREE 



n = total size of the tables 



SO* 



Sl- 




SM 



n-1 



Tree Table Format (one 11 -word Table per Segment) 















Segment Name in 







TEXTC Format 


1 


Displacement x. 
from the beginning^ 




2 


ROM Pointer 




Back Link ** 


3 


of the ROM Tables 


Forward Link** 


Overlay Link** 


4' 


to the first ROM 


00 Size * 


00 Loc* 


5 


Table for this 


REF/DEF Size 


REF/DEF Loc* 


6 


segment 


01 Size* 


01 Loc* 


7 




Expr. Size 


Expr. Loc* 


8 




10 Size* 


10 Loc* 


9 






10 




Figure 12. Tree Tables 

Segment name is determined by the name of the first file in the segment. (If the load 
module has only one segment, i.e. , the root, the keys begin with load module name. If 
no load module name was supplied, the name is id L. 
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Words 5-10 of each Tree Table are computed by the Loader. 

Word 10 of the ROOT Tree Table is used to monitor the size of the REF/BREF Tables. 

*Doubleword address or * of doublewords 

** Displacements from TREE 
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Tree Tables 



Tree Structure 






















— 








SI 



















1 










"~ 














SO 








S3 


S2 
















2 
























SO 














S5 













3 


















"" 




SI 













S4 














4 


r 










'" 




SI 






















5 














S2 











S6 














6 


















S2 





























1 


3 








2 


4 









5 










6 



Tree Table Link Pointers 









back 


sub (fwd) 


overlay 







Figure 13. TREE Table Linking — in Relation to the Overlay Structure 
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Tree Structure 



SEG 3 





SEG 1 


w 




j 




ROM6 
SEG 4 




ROM7 








ROM1 


ROM2 
SEG 2 








SEG 










ROM8 





ROM3 ROM4 ROM5 



LOCCT 






Displacements 







TREE Tables 


//lx\ 


ROM Tables 






ROM Table 


/ i 1 \ \ 


RT ] l\ *\ 
(last) 


1 






1 1 1 




i 






TREE Table 






1 1 1 
1 1 1 




1 , » 


2 
























RT 2 (\ *\ 
(last) 






i 1 i 






1 1 ' 
1 1 ' 

1 1 1 






SEGO 
TT 
























RT3 










"*" 




















RT4 






1 I I 






SEG1 
TT 


1 1 1 

1 1 1 

1 1 1 
1 ' 1 
















RT 5 tx * 
(last) 




















RT 6 














| 1 

, 1 
1 

' 1 






SEG2 
TT 


















RT 7 (\ >\ 
(last) 






















RT8 t\ >\ 
(last) 














SEG3 

TT 












































SEG4 
TT 





Figure 14. LOCCT, TREE, and ROM Table Relationships 
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3.1.2 Files (ROMs and Load Modules) 

The Loader will access ROM files and load module files. All file names specified on the 
!LOAD card under the EF option appear in the ROM Table. Additionally, the files idB 
and idG may appear in the ROM Table if the user specified (BI) or (GO), respectively. 
During Pass One processing, the Loader augments the ROM Table by those library load 
modules which are to be included. Note that the Loader is entirely file-oriented. That is, 
ROMs coming from cards on BI will be read by CCI which creates a file by the name of idB. 
(Exception: M:EF may be assigned to labeled tape. ) 

a. ROM Files 

A ROM file consists of one or more ROMs produced by an assembler or compiler (see 
the BPM Reference Manual (90 09 54) for a description of the ROM language). ROM 
files are accessed either from the accounts specified in the EF list (which the Loader 
sees in the ROM Table) or from the files idB and idG. (If a 1TREE card has been 
included, idB and idG would appear in the ROM Tables for the root segment.) 

b. Load Module Files 

Load modules acceptable for combination with ROMs to form a new load module are 
built either by 

1) the Loader itself, in which case they are library load modules (see Output Section 
3. 2, for format); 

2) PASS2 of SYSGEN; or 

3) DEFCOM processor. 

The HEAD of the input load module indicates one of the above sources in order that 
any attributes may be handled correctly. Any such load module must be of one 
protection type, relocatable, and not overlaid. Furthermore, if such a load module 
contains a DSECT, then the entire load module consists of that DSECT alone. 
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3.1.3 Registers and JIT Input 



BPM 

R6 = word size of LOCCT, ROM, and Tree Tables 
R7 = 



xx 



id 



SRI = information needed by CCI or PASS3. This is 
simply stored and restored upon exit. 

D4 = foreground COMMON bias 



CP- V 

J:EUP = page number of the last user page 

J JIT, byte 3 = id 

JB:BCP, byte 1 = page pointer to LOCCT Table -1. 

This word contains: 



xx 



which is followed by the LOCCT, ROM, 
and Tree Tables. 



SR1,D4 = same as BPM 

xx = 0, if CCI called the Loader, 
/ 0, if PASS3 called the Loader. 

n = size of LOCCT, ROM, and Tree Tables 

id = system id (see Glossary) 
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3.1.4 ASSIGN Record 

CCI builds a record of all ASSIGN information encountered during a job. The Loader 
examines this record to see if any F: number DCBs have been entered and, if so, will gen- 
erate those DCBs with default entries (if they are PREFs within the user program). In CP-V 
this record is read via an FPT code = X'2D'. In BPM the record is in section 35 of absolute 
area of the RAD and is read with an FPT code of X'16'. (See Section 16 of the F00 BPM 
Technical Manual for formats. ) 

3.1.5 Error Message File (ERRMSG) 

This is a keyed file under the :SYS account. Its keys are of the form; 



03 1 02 Terror number ! 



The records are the text error messages. To alter the file, one uses the programs ERROM 
(Cat. No. CN706106) and ERRDATA (Cat. No. SI706107) for BPM, and the program ERRMWR 
for CP-V. 

When an error occurs, the Loader transfers control to MESSAGE (in LDR) with the error number 
in R3. MESSAGE builds the key, reads and prints the associated record. 

Figure 15 is a listing of ERRMSG (to date). 
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KEY 



MESSAGE 



020001 

020002 

020003 

020004 

020005 

020006 

020007 

020008 

020009 

02000A 

02000B 

02000C 

02000D 

02000E 

02000F 

020010 

020011 

020012 

020013 

020014 

020015 

020016 

020017 

020018 

020019 

02001A 

02001B 

02001C 

02001 D 

02001 E 

02001 F 

020020 

020021 

020022 

020023 

020024 

020025 

020026 

020027 

020028 

020029 

02002A 

02002B 

02002C 

02002D 



UNEXPECTED EOF 

ILLEGAL RECORD I. D. 

SEQUENCE ERROR 

ILLEGAL RECORD SIZE 

CHECKSUM ERROR 

ABNORMAL I/O 

CANNOT OPEN E. F. 

STACK OVERFLOW 

BIAS TOO LARGE 

ILL. ROM LANGUAGE 

BAD START ADDRESS 

UNEXPECTED ROM END 

REPEAT LOAD IS ZERO 

IMPROPER BOUND 

ILLEGAL ORG 

BAD I/O RETURN FROM M:LM DCB 

SEV. LEV. EXCEEDED 

ILL. LIB. LOAD MOD. 

NO ROOM TO ROUND DCBS TO PAGE BOUNDARIES. TRY FORCING XMEM 

ILL. DSECT 

ROOT SEGMENT TOO LARGE TO LOAD IN2 

CANNOT ENTER XMEM. NO ROOM FOR CORE IMAGE BUFFER IN2 



CANNOT ENTER XMEM. STACKS TOO LARGE. 

NOT ENOUGH ROOM TO CONCATENATE XMEM PAGES 

NO ROOM TO READ LIBRARY CORE IMAGE 

NO ROOM TO READ LIBRARY RELOCATION DICTIONARY. 

NO ROOM FOR NEW EXPRESSION 

NO ROOM TO BUILD DCB TABLE. TRY FORCING XMEM 

NO ROOM TO BUILD DCB TABLE 

LIBRARY LOAD MODULE REF/DEF STACK TOO LARGE TO UPDATE 

INSUFFICIENT PHYSICAL MEMORY 

BAD ASSIGN/MERGE RECORD 

NO ROOM TO ADD LIBRARY LOAD MODULE TO ROM TABLE 

NO ROOM TO READ LIBRARY REF/DEF STACK 

NO ROOM TO UPDATE LIBRARY 

INVALID KEY SUPPLIED) FOR DELETE RECORD ON M:DIC 

I/O ERROR ON M:DIC IN WRITESEG 

ILLEGAL LIBRARY LOAD MODULE NAME 

ABNORMAL I/O ON OPEN OR READ TO CORE LIBRARY 

INVALID DECLARATION NUMBER REFERENCE (BAD ROM). 

INVALID KEY SUPPLIED FOR WRITE RECORD ON M:DIC 

ILLEGAL LOADER TRAP 

ABNORMAL I/O IN WRITELIB 

CANNOT FIND REF/DEF NAME IN STACK 

LIB LOAD MODULE TOO BIG - CANNOT USE EXTENDED MEMORY 

Figure 15. ERRMSG File 



IN2 
IN2 
EVL 
TRY FORCING XMEM 
WRT 
WRT 
WRT 
WRT 



41 



KEY MESSAGE 

02002E LIB LMN IS NOT ALLOWED ON A PRIVATE VOLUME 

02002F ABNORMAL I/O READING LIB LMN 

020030 PAGED LMN MUST NOT HAVE MORE THAN 256 SEGMENTS 

020031 LMN'S SIZE TOO BIG 

020032 EXISTING LMN CANNOT BE MAPPED - X'85 1 

020033 BAD ENTRY IN LIBRARY REF/DEF STACK 

Figure 15. ERRMSG File (cont. ) 
3.1.6 Modify File (idP) 

This keyed file is built by CCI in the user's account on the basis of the IMODIFY cards. 

Its keys are of the form: 

TEXTC segment name concatenated with xx, where < xx < n and 
n = the hexadecimal number of IMODIFY cards. 

See Section 16 of the F00 BPM Technical Manual for a more detailed format. 



3.1.7 Core Libraries (CP-V onl y) 

Core libraries exist only under the :SYS account. An absolute copy of a core library's 
procedure area exists on swap storage associated with the name :Pnnn and is placed at 
run-time into a fixed area. The DEFs for :Pnn which relate the core library's context 
area (preceding the user's blank COMMON) with the user and the library procedure are 
contained in a load module (formed by DEFCOM) named :Pn. The Loader's job is to read 
:Pn, merge the DEFs into the REF/DEF stack of the target load module, and signal the 
!RUN processor that it is to associate :Pnn with this program. The signal consists of 
placing the text :Pnnn in the HEAD record of the load module. 

:P0 is the name of the FORTRAN core library with debug. 
:P1 is the name of the FORTRAN core library without debug. 

See Chapter 6 of the CP-V System Management Guide for details on core libraries. 
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3.2 OUTPUT 

3.2.1 Load Modules, Overall Format 

A load module is a keyed file whose name was supplied on the 1LOAD card (default = idL). The 

keys and records are as follows: 

Record 



a. Key - 
HEAD 



BPM 












8 


16 


24 31 





8X 


00 


FF 


n 




A 


B 


SL 




START address 


2 


TCB* 


Module Bias* 


3 


DATA (00) Base* 


PROCEDURE (01) Base* 


4 


STATIC DATA (10) Base* 


Next Available Page* 


5 


MAX RF/DF SIZE 


TREE Size 

-i-n 



CP-V 



8X 


00 


FF 


n 


A 


B 


SL 




START address 


TCB* 


Module Bias* 


DATA Size* 


DATA (00) Base* 


PROCEDURE SIZE * 


PROCEDURE (01) Base* 


MAX RF/DF Size 


TREE Size 


DCB Size* 


DCB Base (10)* 

































(Footnotes are on next page.) 
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Footnotes to keys and records shown on previous page: 

*Doubleword address 

In byte 0, word X = 0, load module produced by Loader. 

= 1, load module produced by SYSGEN. 
= 2, library load module produced by Loader, 
= 3, load module produced by DEFCOM (con- 
sists of HEAD, TREE, and REF/DEF (Stack). 
- 5, paged load module produced by Loader. 

n = number of bytes in the HEAD record. For CP~V, n = X'30'; for BPM, n - X'18\ 

A = 1, abs module 

B = 1, NOTCB 

SL = Final Severity Level 

** Word 7 If DEFCOM output, this word = byte size of DATA area. 

*** Words 9, A, B If the LMN is associated with a core library, these words 

are :Pnnn in TEXTC format. 



b. Key = TREE Record is the Tree Tables (see Figure 12), 

c. Segment Components - Standard Load Module 

For each segment, the following records are built: 

Key Record 



-►REF/DEF stack 
-►EXPR stack 
-►00REL DICT 
"►00 Control Sections 



Segmenj Name v Q4 __ R£L D]CT 

Concatenated with: J -. to _. - L . c l# 

^5 ___ „ ►Ol Control Sections 

)6 ►lO REL DICT 

)7 ► 10 Control Sections 



d. Segment Components - Paged Load Module 

For each segment, the expression stack and REF/DEF stack records have the same 
format as those for the standard load module. Relocation dictionary records are 
not constructed. 
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The core images are partitioned into records of at most 512 words in length with 
3-byte keys of the following format: 



SEG 


00 


PAGE 



where SEG = the TREE segment number of the segment containing the core image. 
PAGE = the page number of the virtual page that will contain this record at 
execution time. 

All core image records are one page in length except for the first record of on overlay 
segment's 00, 01, and 10 areas. The length of this record satisfies the following: at 
execution time, the record begins at the execution bias for this protection type and 
ends at the next page boundary. 

3.2.2 Library Load Modules 

A library constructed by the Overlay Loader consists of two keyed files, :LIB and :DIC. 
The library load modules actually reside in one file (: LIB) . :DIC is a dictionary whose 
keys are the text names of DEFs. The record associated with a dictionary key is the text 
name of the load module (within :LIB) in which that DEF is defined. Thus, in order to lo- 
cate the unique group of records within :LIB which pertain to a given PREF, the Loader 
does a keyed READ to :DIC, the key being the PREF which is being satisfied. This keyed 
READ returns the library load module name within : LIB . With this information the Loader 
can then read the library load module records into core and merge them with the target 
load module. 

The keys and records in :LIB are identical to those of non-library load modules (see above) 
except that the keys "HEAD" and "TREE" are concatenated with the TEXT load module 
name (to keep them unique). Each individual library load module name is "synonymous" 
(in a file sense) with the name :LIB. 

A slight difference also exists in the REF/DEF and expression stack formats. The VALUE 
word of an entry in the REF/DEF stack is actually the head of a chain through the expres- 
sion stack of all those entries which involve that REF/DEF. (This expedites subsequent 
merging of the stacks when the library is included in a user program.) 
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3.2.3 REF/PEF Stack 

There is one REF/DEF stack for each segment. A REF/DEF stack is composed of entries for 
every control section and forward reference in the segment. It also contains an entry for every 
name (DEF, REF, SREF) in the segment which does not occur in this segment's backward path. 



Before a name is added to a segment's REF/DEF stack, the segment's stack and the REF/DEF 
stacks for this segment's backward path are searched. If the name is not in these stacks, a new 
entry is added to the segment's stack. If the name already exists, the entry in which the name 
appears is treated as follows: 

New Name 

DEF 

DEF 

DEF 

REF 

REF 

REF 

SREF 

SREF 

SREF 



Type of Existing 


Modification of 


REF/DEF Entry 


Existing REF/DEF Entry 


DEF 


Double DEF 


REF 


DEF 


SREF 


DEF 


DEF 


Used DEF 


REF 


No change 


SREF 


REF 


DEF 


Used DEF 


REF 


No change 


SREF 


No change 
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GENERAL REF/DEF STACK FORMAT 



1112 15 



31 



TYPE 



VALUE 



RESOLUTION 



where: 

n = number of words in this entry. 
E = 1, if the entry has a VALUE 

TYPE = 0or8 DEF 

1 SREF 

2 PREF 

3 or B Dummy Section 

4 or 6 Control Section 

5 or 7 Forward Reference 

VALUE = constant or address if the load module is not a library 

or 
head of a chain in the expression stack if the load module 
is a library (see SQZ, Section 7.0). 

RESOLUTION = the resolution in which the VALUE is expressed. Resolution 
is of the form: 







16 



31 



byte 


half 


word 


double 



If the VALUE is a constant, the RESOLUTION word is 0. 

If the VALUE is an address, one and only one byte of the 
RESOLUTION word is nonzero (viz., the appropriate byte = X'01'). 

If the RESOLUTION assumes a form different from either of the above, 
the VALUE is of mixed resolution. (In this case the load module 
cannot be relocated and is forced ABS.) 
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TYPE = 0or8(DEF) 



11 12 15 16 



29 303 



^^}e|0 or 8 



DISP 



U 



VALUE 



RESOLUTION 



1 



Name in TEXTC 



T 



where: 

TYPE = 0, this entry is a DEF. 

= 8, this entry is a double DEF. 
E =1, the DEF has a value. 
DISP = Displacement to the segment in the Tree Table where the 

DEF is located. 
U =1, used DEF (the DEF has been referenced). 
L =1, the DEF was defined in a library. 



| TYPE = 1,2 (SREF or REF)" 



7 




12 1516 


31 


n 




1 or 2 


< > 


yT'., 








/ . 


■-■• '/ ' 




T 


Name in TEXTC 


T 



TYPE = 1, SREF 
= 2, PREF 
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I TYPE = 4 or 6 (Control Section) 



89 11 12 1516 



31 



03 



PP 



*!F 



4 or 6 



SIZE 



VALUE 



RESOLUTION 



where: 

TYPE = 4, when first declared in PASS1 (LP1). 

= 6, after rereading the declaration in PASS2 (LP1 of EVL). 

PP = protection type. 

E = 1, if entry has a value. 

SIZE = size of the control section, in doublewords. 

NOTE: A special entry is created by the Loader and inserted in front 
of a library load module's REF/DEF stack. It has a TYPE = 4, 
but can be detected (in PASS2) because all previous control 
sections would have been changed to 6 by this time. 








8 9 


11 


2 1516 




3 


03 


??[ 


E 


4 


SIZE 


VALUE 


EXP SIZE 


EXP DISP 



w 



here: 

SIZE 
VALUE = 

EXP SIZE- 
EXP DISP- 



Size of the load module's core image in doublewords. 
Location of this load module's core image (within 
the target load module). 

Word size of the load module's expression stack. 
Displacement of load module's expression stack 
within this segment's expression stack. 
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TYPE = 3 or B (Dummy Control Section) 



7 89 1011 12 1516 



31 



n 


k 


rn ■■-■ 

/ E3orB 


"' 


SIZE 


VALUE 


RESOLUTION 


Name of DSECT 
(or DCB) in TEXTC 



where: 

TYPE = 3, Dummy Control Section 

= B, At the end of PASS1, all PREFs (TYPE2) with names 
beginning with M: or F: are changed to TYPE B, 
indicating that the Loader is to build them at the 
end of the second pass. 



TYPE = 5 or 7 (Forward Reference) | 








78 


1011 12 15 


b 31 


04 


<2? 


F 


E 


5or7 




VALUE 


RESOLUTION 


K 




Forward Reference Number 



w 



here: 



TYPE = 5, Forward Reference. 

= 7, Forward Reference is defined from a library. 
K =0, Until the forward reference is defined. 

=FF, Define forward REF and "release" the reference number. 
=F0, Define forward REF and hold the reference number until 
module end. 
F =1, the forward reference is used in a "Define forward reference 
and hold" expression. 
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3.2.4 Expression Stack 

The Loader builds an entry in the expression stack by re -for matting a ROM expression. This 
re-formatting process consists of grouping all of the control bytes together in one part of the 
entry, and all of the operands in another. If the ROM operand is a constant, it is transferred 
verbatim from the ROM to the operand portion of the entry. If the ROM operand is a declara- 
tion number, the REF/DEF stack pointer is accessed from the declaration stack and placed in 
the operand portion of the expression entry. If the ROM operand is a forward reference number, 
the corresponding REF/DEF stack pointer is transferred to the operand portion of the entry. 
Some control bytes have no operands (viz., expression end or change resolution) and therefore, 
have no corresponding item in the operand portion. Thus, the control byte portion of the entry 
is related sequentially to the operand portion, except in the case where no operand exists. 

The value of an expression is deposited either in a REF/DEF stack entry or in a field in the core 
image of the target load module. (See Section 2. 1. If). In the first case, the destination of 
the expression's value is described by a pointer to the entry in the REF/DEF stack. In the 
second case, the destination is described by a core expression. A core expression contains the 
field size, in bits (which can cross up to eight words of the core image); the address of the last 
word in the core image to be changed; and the terminal bit position of the field. 
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GENERAL EXPRESSION STACK ENTRY 






7 89 10 15 


24 




31 


1 


n 


EC 


DISP 


CB 1 


CB 2 


2 


CB 3 


CB 4 




















Desti nation 




Resolution 




Word j 




Word 2 




• 


n 


Word 
m 



where: 

n = number of words in entry 

E = 1, this entry has been evaluated. 
= 0, this entry has not been evaluated. 

C = 0, this entry's Destination is a pointer to the REF/DEF stack. 
= 1, this entry's Destination is a core expression. 

DISP = number of words to Word 1. 

Destination: (where the value of the entry is to be deposited) = 

one of the following forms, depending upon the value of C. 



If C = 



If C= 1 



REF/DEF Pointer 






15 


16 31 


Segment's Displacement 
in Tree Table 


Displacement within 
segment's REF/DEF stack 


Core Expression 
7 8 14 15 31 


Field Size 


Terminal 
Bit Position 


Word Address 



Resolution: 

CB. = 
i 

Word. = 
i 



Same as REF/DEF stack, 
a control byte of the expression. 

is referenced by a control byte and is a constant 
or pointer to the segment's REF/DEF stack (same 
form as Destination where C=0). 
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NOTE: A special entry is created by the Loader and inserted 
in front of a library load module's expression stack. 
It has n = 3, DISP = 4, and is marked as evaluated 
in the following format: 



78910 15 


16 23 24 31 


3 


1 


4 


02 




Displacement of this lib Imn's special REF/bEF entry 
in the REF/bEF stack. 


Word resolution 
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3.2.5 Relocation Dictionary 

If ABS is not specified on the ILOAD card, each segment will have records of relocation 
dictionaries (one per protection type). One relocation digit is developed for each word in 
the protection area. 

Relocation Dictionary Digits 

Digit Type of Relocation 

relocate the word at byte resolution. 

1 relocate the word at halfword resolution. 

2 relocate the word at word resolution. 

3 relocate the word at doubleword resolution. 

8 relocate the left half of the word at doubleword resolution, 

9 relocate the right half of the word at doubleword resolution. 
A relocate both halves of the word at doubleword resolution. 

E absolute. 

Notice that relocation digits exist only for items that terminate on halfword boundaries. 

A load module which has an item not amenable to one of these digits is set to ABS, 
Example: BQUND 4 

ZAP EQU DA($) 

GEN, 8, 16, 8 0, ZAP,0 

or 

BOUND 4 
ZAP EQU $ 

GEN, 3, 17, 12 0, ZAP,0 

Either of these would cause the module to be set ABS since ZAP does not terminate on 

a halfword boundary. 
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3.2.6 Miscellaneous (Map, Diagnostics, Severity Level) 

The map, diagnostics, and the severity level of the load module are output via the 
M:LL DCB (normally the printer): 

a. Load Map 

The load map is generated at the end of the load process. For each segment, the 
map includes: 

i) A header consisting of the segment name and size. For the root segment, the 

load module name, account number, start address, and bias are also listed. 

ii) A summary of the segment's protection type boundaries and sizes of the format: 

****PROTECTION TYPES: 00 DATA 01 PROCEDURE 10 STATIC 

SEGHI-0 valhi SEGHI-0 valhi SEGHI-2 valhi 
SEGLO-0 vallo SEGLO-1 vallo SEGLO-2 vallo 
OOSIZE-size 01 SIZE=size 10 SIZE=size 

where valhi = the high word address for this protection type. 

vallo = the start address (word resolution) for this protection type, 
size = the size, in words, of the protection type area. 

iii) A list of any unsatisfied primary references (PREFs). 

iv) A list of any unsatisfied secondary references (SREFs). 

v) A list of any multiply-defined definitions (DDEFs). 

vi) A list of definitions with absolute values (ADEFs). 

vii) A list of relocatable definitions and control sections for this segment, sorted 
either by value or by name. A value sort produces a list of the DEFs and 
control sections in increasing value, with a new line started for a CSECT or 
DSECT. The control section's address and protection type is noted in the left- 
hand margin of this line and its size is noted in the right-hand margin. 

A name sort really produces two lists. The first list, entitled 'SECT-PROGRAM 
SECTIONS MAP' contains the control sections (in increasing value) and the 
first DEF in each section. One (lowest in value) control section, its first 
DEF, and the control section size is printed on a single line. The second 
list, entitled 'RELOCATABLE DEFINITIONS SORTED BY NAME', lists the 
DEFs, sorted alphanumerically by name over the entire segment. 
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In both the value and name type of DEF lists, the control sections are printed 
in the format: 

, fCSECTl 
va,ue lDSECTl P 

where p = the protection type of the control section. 

value = the word address at which this section begins. 

The relocatable DEFs have the format: 
value r symbol 

where value = the value of the definition, expressed as a word address. 

r = the byte displacement (i.e., the two high order bits of the value if 
it were expressed as a byte address). 

symbol = the symbolic name of the item. 

The following flags can precede the symbolic name of a DEF (or ADEF). 

* = unused definition. 

+ = multiply defined definition. 

- = definition satisfied from a library. 

The map for each segment starts on a new page. For the lists (iii)-(vii), 
four symbols are listed on a line unless there is a large symbol which cannot 
fit in one column. In this case the symbol is printed on a single line. Lists 
(iii)-(vi) are always sorted by name. 

b. D iagnostics 

The diagnostic consists of the pertinent record obtained from the ERRMSG file and 
the following information: the name of the element file currently being processed, 
the sequence number of the record most recently read, and a third field of data 
pertinent to the particular error that occurred. (See Figure 15b for a list of the 
error message keys and the corresponding data printed in this field.) 

c. Severity Level 

A nonzero severity level is printed at the end of the load process immediately before 
the map is printed. The final severity level is actually the maximum of any severity 
levels inherited from the ROMs and those generated internally by the loader. 
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Internal Loader-generated Severity Levels: 

Type of Error Severity 

PREF 7 



DDEF 

REF load table exceeded 

BREF load table exceeded 



6 for CP-V, 3 for BPM 
(After printing the final severity level, it is compared with the maximum specified 
by the user (for CCI). If it is greater loading is aborted). 



d. Register Output for PASS3 

D4 = if normal return. 

= -1 if abnormal return. 
SRI = original contents upon entry to the Loader. 



ERROR KEY 


Diagnostic Information Output 


020001 


SR3 


020002 


Record I.D. 


020003 


(none) 


020004 


Record Size 


020005 


(none) 


020006 


SR3 


020007 


SR3 


020008 


SR3 


020009 


Bias 


02000A 


Object Module Control Byte 


02000B 


Start Address 


02000C 


(none) 


02000D 


(none) 


02000E 


Byte addr of load relocatable destination 


02000F 


SR4 (for debugging purposes) 


020010 


SR3 


020011 


Computed Severity Level 


020012 


(none) 


020013 


No. of words to be added to 10 area 


020014 


1st 4 characters of DSECT name 


020015 


No. of words exceeding available background 


020016 


(none) 


020017 


No. of words that stacks exceed available background 


020018 


No. of words exceeding available background 


020019 


No. of words in library's core image and rel . diet. 



Figure 15b. Variable Diagnostic Information 
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ERROR KEY 


Diagnostic Information Output 


02001 A 


Size of relocation dictionary 


02001 B 


(none) 


0200 1C 


(none) 


0200 ID 


No. of words in DCB Name Table and its rel . diet. 


02001 E 


(none) 


0200 IF 


Register 


020020 


SR3 


020021 


High addr. of REF/DEF stack (which would overwrite exprstk) 


020022 


Size of library load module's REF/DEF stack 


020023 


Size of REF/DEF stack corresponding to old version of library Imn 


020024 


Key Size 


020025 


SR3 


020026 


No. of characters in load module name 


020027 


SR3 


020028 


Invalid Declaration Number 


020029 


Key Size 


02002A 


Register 


02002B 


SR3 


02002C 


1st 3 characters and byte count of name 


02002D 


(none) 


02002E 


(none) 


02002F 


SR3 


020030 


(none) 


020031 


(none) 


020032 


1st 4 characters of DSECT name 



Figure 15b. Variable Diagnostic Information (cont. ) 



DESCRIPTION OF COMMON LOADER ERROR MESSAGES 



UNEXPECTED EOF 

ILLEGAL RECORD I. D. 

SEQUENCE ERROR 
ILLEGAL RECORD SIZE 

CHECKSUM ERROR 



An end-of-file was encountered before the end of an object 
module was reached (incomplete object module). 

The type of record read was neither X'3C nor X'lC (object 
module), nor X'81', X'82', or X'83* (Load Module). 

The cards of an object module were out of sequence. 

The number of bytes in an object module card was less than 
four or greater than X'6C. 

A bit (or bits) was stopped in punching or reading the object 
module. 
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Table 1. Load Error Messages (conr.) 



Key 


Message 


Description 


CODE/SIZE/SL Field 


02001 A 


NO ROOM TO READ 
LIBRARY RELOCATION 
DICTIONARY. TRY 
FORCING XMEM. 




Size of relocation 
dictionary 


0200 IB 


NO ROOM FOR NEW 
EXPRESSION 




(None) 


0200 1C 


NO ROOM TO BUILD 
DCB TABLE. TRY FORC- 
ING XMEM. 




(None) 


0200 ID 


NO ROOM TO BUILD 
DCB TABLE 




Size of DCB table 


0200 IE 


LIBRARY LOAD MODULE 
REF/DEF STACK TOO 
LARGE TO UPDATE 




(None) 


0200 IF 


INSUFFICIENT PHYSICAL 
MEMORY 


See "Stack Overflow" description 
(Key 020008). 


R0 (for debugging) 


020020 


BAD ASSIGN/MERGE 
RECORD 




SR3 


020021 


NO ROOM TO ADD 
LIBRARY LOAD MODULE 
TO ROM TABLE 




Top of REF/DEF Stack 


020022 


NO ROOM TO READ 
LIBRARY REF/DEF STACK 




Size of library Imn's 
REF/DEF Stack 


020023 


NO ROOM TO UPDATE 
LIBRARY 




REF/DEF Stack size of 
old version of this Imn 


020024 


INVALID KEY SUPPLIED 
FOR DELETE RECORD 
ON M:DIC 


Cannot update :DIC for this library load 
module. 


Key size 


020025 


IO ERROR ON M:D1C IN 
WRITESEG 


Cannot update :DIC for this library load 
module. 


SR3 


020026 


ILLEGAL LIBRARY LOAD 
MODULE NAME 


The name is > 12 characters. 


Number of characters 
in name 


020027 


ABNORMAL I/O ON 
OPEN OR READ TO CORE 
LIBRARY 




SR3 


020028 


INVALID DECLARATION 
NUMBER REFERENCE 
(BAD ROM) 


An expression in a relocatable object module 
contains a reference to an unassigned decla- 
ration name number (assembler or compiler 
error). 


The bad declaration 
number 
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90 18 03C- 1(9/74) 



Table 1. Load Error Messages (conf . ) 



Key 


Message 


Description 


CODE/SIZE/SL Field 


020029 


INVALID KEY SUPPLIED 


A DEF name in a library load module was not 


Key size 




FOR WRITE RECORD ON 


in the legal range of 1-63 characters. 






M:DIC 






O2002A 


ILLEGAL LOADER TRAP 


Loader error. When such errors occur, the 
loader takes memory snapshots for use in iden- 
tifying the error. 


Register 


02002 B 


ABNORMAL I/O IN 
WRITELIB 


The :LIB file could not be opened. 


SR3 


O2002C 


CANNOT FIND REF/DEF 


The loader encountered a new REF/DEF name 


Byte count and first 




NAME IN STACK 


during its second pass. 


3 characters of name 


O2002D 


LIB. LOAD MODULE 


Extended memory mode has been entered (be- 


(None) 




TOO BIG -CANNOT 


cause the core image is too large to be formed 






USE EXTENDED 


in one piece) and the load module has been 






MEMORY 


forced ABS (illegal for library Imn's). 




O2002E 


LIB LMN IS NOT 
ALLOWED ON A 
PRIVATE VOLUME 




(None) 


O2002F 


ABNORMAL I/O READ- 


An abnormal return was encountered while 


SR3 




ING LIB LMN 


reading a library load module during the 
loader's second pass. 




020030 


PAGED LMN MUST NOT 




Number of segments 




HAVE MORE THAN 




specified 




256 SEGMENTS 






020031 


LMN'sSIZE TOO BIG 


The size (in doublewords) of a protection type 
of the load module does not fit in the halfword 
allowed for it in the tree. 


(None) 


020032 


EXISTING LMN CAN- 
NOT BE MAPPED -X'85' 




(None) 


020033 


BAD ENTRY IN LIBRARY 
REF/DEF STACK 




(None) 



90 18 03C -2(4/75) 
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3.3 LOADER-GENERATED TABLES 

All loader -generated tables reside in the root segment of the load module in the 
order indicated by Figure 1. Loader-generated tables are the TCB, Tree Tables, 
DCB Name Table, REF/BREF Tables, and DCBs. 

3. 3. 1 Formats for the TCB and DCB Name Table are in the BPM Reference Manual. 

The TCB resides in 00. The DCB Name Table resides in 01 for BPM and 10 for CP-V. 

3. 3. 2 TREE. A copy of the Tree Tables (see Figure 12) is placed at the beginning of the 
01 area (as well as being separately recorded in the TREE record). 

3. 3. 3 REF/BREF Tables 
REF mode 



An entry is .created for every load item involving a REF defined in a higher segment. 
The load item is replaced by a CAL1,8 X where X is the REF Table entry address 
( a PLIST for the CAL). 



X 



18 











SEG 


Replaced load 


item. 






B load item 


+ 1 







SEG = 17 bit address of higher 

segment name in Tree Table. 



BREF 

An entry is created for every branch type instruction involving a REF to a higher 

segment. The branch type instruction is replaced by a branch (of the same type) to the 
BREF entry. 
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BAL,RO S:OVRLY 


* 


SEG 

■ ■ - ■ ■ "" « 


X 

1 


ADDR 



where: S:OVRLY is a system library routine 

SEG = segment number (Tree Table displacement/11) 

ADDR = address field of replaced instruction 

*,x = indirect and index fields from replaced instruction 

EXAMPLE: 

Assume that a segment S references ZAP (defined in a higher segment): 
Segment S 

REF ZAP 



* BAL,7 *ZAP 



If REF loading mode: 



a CAL1,8 
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1 


80 







SEG 


BAL,7 




*ZAP 


B 




+ 1 



SEG is as defined for 
REF above. 



If BREF loading mode: 



« BAL,7 







/3 



BAL,R0 S:OVRLY 

1| SEG |0000 1 ZAP 



SEG is as defined for 
BREF above. 



3.3.4 DCBs 



The Loader will build a DCB if, at the end of PASS1, there exist any PREFs which begin 
with M: or F:. This can occur if: 1) CCI's ASSIGN record contained F: number 
entries; 2) the user had a REF DCB name and had no ROMs or libraries which satisfied 
this REF; 3) the NOTCB option is absent, whereupon an M:DO is generated; 4) a .'TREE 
card is present, whereupon an MrSEGLD is generated. 

All Loader-generated DCBs are DSECTs whose allocation is forced to the root. The 
standard 22 words are allocated for the fixed portion of the DCB. In the variable length 
parameter portion of the DCB, three words are allocated for file name, two words for 
account, two words for password, three words for INSN numbers, and three words for 
OUTSN. Two additional words are allocated for an EXPIRE date for CP-V DCBs. The 



62 



total DCB size is 48 words for BPM, 51 words for CP-V. Default information is placed 
into recognized DCB names. The recognized DCB names and their defaults are shown 



in Figure 16. 








DCB 




RECORD 


OPERATIONAL 


NAME 


FUNCTION 
Input 


BYTE SIZE 
120 


LEVEL 


M:C 


C 


M:OC 


Input/Output 


85 


OC 


M:LO 


Output 


132 


LO 


M:LL 


Output 


132 


LL 


M:DO 


Output 


132 


DO 


M:PO 


Output 


80 


PO 


M:BO 


Output 


120 


BO 


M:LI 


Input 


120 


LI 


M:SI 


Input 


80 


SI 


M:BI 


Input 


120 


BI 


M:SL 


Output 


132 


SL 


M:SO 


Output 


80 


SO 


M:CI 


Input 


120 


CI 


M:CO 


Output 


120 


CO 


M:AL 


Output 


80 


AL 


M:EI 


Input 


120 


EI 


M:EO 


Output 


120 


EO 


M:GO 


Output 


120 


NO 


F:101 


Input 





OC 


F:102 


Output 





OC 


F:103 


Input 





PR 


F.-104 


Output 





PP 


F:105 


Input 


80 


SI 


F:106 


Output 


120 


BO 


F:108 


Output 


132 


LO 



Figure 16. Recognized DCBs and their Defaults 



For CP-V, nonstandard DCBs (i.e., those not listed in Figure 16) are assigned to 'ME', 
which goes to the terminal for an on-line user or to device 'NO* for batch. 
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3.4 EXAMPLES 

The following example is designed to illustrate: 1) a load module's expression stack 
in relation to its REF/DEF stack, and 2) the correspondence of these two stacks to 
the ROM from which they were derived. This example should also clarify many of the 
files and tables discussed in this chapter. 

3. 4. 1 A Sample Program 

The following program was assembled under the METASYM processor. 



1 












SYSTEM 


SIG7FDP 


2 












DEF 


AB1 


3 












REF 


AB2 


4 


01 


00000 


6A900000 


X 


START 


BAL,9 


AB2 


5 


01 


00001 


00000008 


02 




DATA 


ZAP+2 


6 


02 


00000 








CSECT 





7 


02 


00000 








RES 


5 


8 


02 


00005 


000000FF 


A 


AB1 


DATA 


X'FF' 


9 




02 


00006 




ZAP 


EQU 


$ 


10 




01 


00000 






END 


START 



CONTROL SECTION SUMMARY: 01 00002 PT 02 00006 PT 



3. 4. 2 The ROM 



Following is a load-item-by-load-item interpretation (known as a ROMBUST) of the ROM 
for this program. The load items are interpreted in the order that they were output by 
the METASYM processor. Note that each load item is listed, in hexadecimal, on the line 
immediately above its verbal description. 
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ROMBUST OF SAMPLE PROGRAM 
RECORD NUMBER: 

RECORD TYPE: LAST, MODE: BINARY, FORMAT: OBJECT LANGUAGE. 
SEQUENCE NUMBER 
CHECKSUM: 200 
RECORD SIZE: 66 

0303C1C2F1 

DECLARE EXTERNAL DEFINITION NAME (3 BYTES) NAME: AB1 DECLARATION 
NUMBER : 1 



0503C1C2F2 

DECLARE PRIMARY REFERENCE NAME (3 BYTES) NAME: AB2 DECLARATION NUMBER 
2 

0C000008 

DECLARE NONSTANDARD CONTROL SECTION DECLARATION NUMBER: 3 

ACCESS CODE: FULL ACCESS. SIZE 8 X^' 

0C000018 

DECLARE NONSTANDARD CONTROL SECTION DECLARATION NUMBER: 4 

ACCESS CODE: FULL ACCESS. SIZE 24 X'18' 



0A01 01 00000014200402 

DEFINE EXTERNAL DEFINITION 

NUMBER 1 

ADD CONSTANT: 20 X'14 1 

ADD VALUE OF DECLARATION (BYTE RESOLUTION) 

NUMBER 4 

EXPRESSION END 



04200302 

ORIGIN 

ADD VALUE OF DECLARATION (BYTE RESOLUTION) 

NUMBER 3 

EXPRESSION END 



826A900000 

LOAD RELOCATABLE (SHORT FORM). RELOCATE ADDRESS FIELD (WORD RESOLUTION) 

RELATIVE TO DECLARATION NUMBER 2 

THE FOLLOWING 4 BYTES: X'6A900000' 
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8400000008 

LOAD RELOCATABLE (SHORT FORM), RELOCATE ADDRESS FIELD (WORD RESOLUTION) 

RELATIVE TO DECLARATION NUMBER 4 

THE FOLLOWING 4 BYTES: X'8' 

040100000014200402 

ORIGIN 

ADD CONSTANT: 20 X '14' 

ADD VALUE OF DECLARATION (BYTE RESOLUTION) 

NUMBER 4 

EXPRESSION END 



44000000FF 

LOAD ABSOLUTE THE FOLLOWING 4 BYTES: X'OOOOOOFF' 

0D220302 

DEFINE START 

ADD VALUE OF DECLARATION (WORD RESOLUTION) 

NUMBER 3 

EXPRESSION END 



0E00 

MODULE END 
SEVERITY LEVEL: X'0' 
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3.4.3 The Load Module 



The following load card was used to form a load module for this program: 
ILOAD (EF, (SAMPLE)), (NOTCB), (SL,A), (LMN, TARGET) 
(Where the ROM was located in the file with name SAMPLE). 
The resultant load module is listed below. 

TARGET LOAD MODULE 

HEAD 

00 8000FF18 47006F00 00003700 37003800 39003900 0011 000C 

07E3C1D9C7C5E300 

00 03160000 00006E00 00000100 04100000 0001 B81C 01000000 03C1C2F1 04020000 
08 00000000 00000000 03C1C2F2 03160001 00006E00 00000100 03160003 00006F02 
10 00000100 

07E3C1D9C7C5E301 

00 06840120 02000003 00000003 01000000 00000014 0000000E 04432202 113E6F00 

08 00000000 00000007 

07E3C1D9C75E302 
00000 E2EEEEEE 

07E3C1D9C7C5E303 

00 6A900000 00006E0A 00000000 00000000 00000000 00000000 00000000 000000FF 

07E3C1D9C5E304 

00 2EEEEEEE 9E9E99EE EEEEEE 

07E3C1D9C7C5E305 

00 00000000 00000000 0000000C 06E3C1D9 C7C5E301 40404040 00000000 00000000 

08 00043700 00113E38 000B3800 000A3E53 00003900 00000000 00000000 00000000 

10 00000000 06040120 02000003 00000003 00000000 00000014 

TREE 

00 0000000C 06E3C1D9 C7C5E305 40404040 00000000 00000000 00043700 00U3E38 

08 000B3800 000A3E53 00003900 00000000 
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DISPLACEMENT 


FROM STACK BASE 


Word 


Word 3 


Word 7 


Word B 


Word E 



3.4.4 The Relationship Between the Expression Stack and the REF/DEF Stack 

The REF/DEF stack of the preceding load module (the second record listed) has entries 
as follows: 
TYPE 

Control Section 
DEF (of AB1) 
PREF (of AB2) 
Control Section 
Control Section 

The first REF/DEF entry is a special control section and corresponds to Declaration 

Number (for one-pass assemblers and compilers). The subsequent four entries reflect 

Declaration Numbers 1, 2, 3, and 4 made in the ROM. 

The expression stack (the third record of the load module) contains two entries. The loader 
reads the first entry as follows: 1) Add the constant 14 to the expression accumulator; 
2) Get the value word of that REF/DEF entry which begins at Word E of the REF/DEF Stack 
(a control section); 3) Change the value word, if necessary, to byte resolution and add it 
to the expression accumulator; 4) Store the result in that REF/DEF entry which begins 3 
words into the stack (the DEF). The "result" signifies both the sum in expression 
accumulator, which goes into the value word of the DEF, and the resolution of the expressior, 
which goes into the resolution word of the DEF. Notice that a similar expression appears 
in a load item of the ROM, and that the loader built its expression entry by re-formatting 
the ROM's expression. 

Looking at the second expression, the fact that Bit 9 of its first word is set indicates that 
this is a core expression. The expression says to add the value of that REF/DEF entry 
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beginning at word 7 of the Stack (the PREF), at word resolution, to a word in the core 
image. (In fact, the core image word is Word of the fifth load module record. ) 
This expression was constructed because the Loader could not completely satisfy the 
first "load relocable" load item in the ROM (which involves a PREF in the address field). 
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4. DESCRIPTION OF THE FIRST PASS 

Overall execution of the Loader is controlled by the driver within the LDR segment beginning 
at location LOADER. Exit from the Loader back to CCI or PASS3 always occurs at 
location LEAVE within the driver. If an error occurs during processing, control is 
transferred to MESSAGE with the error number. MESSAGE builds the key, reads the 
ERRMSG file, prints the offending error (and the key) and transfers to LEAVE. 

4.1 INIT1 -INITIALIZATION FOR THE FIRST PASS 

INI obtains memory by the method described in Section 2.4. It then zeroes 

its own data page (in LDR) and reads the LOCCT, ROM, and Tree Tables. Knowing the 
size of these tables, the declaration, REF/DEF, and expression stack pointers are now 
initialized. Sixty-four words are set aside for the declaration stack. The REF/DEF Stack 
follows. TOPOMEM is computed (from J:EUP in the JIT if CP-V or on the basis of the 
number of pages given to the Loader if BPM^ and the expression stack pointers are set. 

Dynamic PLISTS are moved into dedicated areas of the DATA page for future use and, 
since CCI did not clear the last six words of each Tree Table, INIT1 does 
so now. 

The ASSIGN record is scanned for F: number DCB names and these are entered as 
PREFs in the REF/DEF stack for future building by the Loader (if they do not get satisfied 
during PASS1). Unless NOTCB was specified, MjDO is also primary- referenced to allow 
for SNAPs and PMDs. If the load module is overlaid, M:SEGlDis primary-referenced for use 
by the segment I oader. If BREF was specified, the library routine S:OVRLY is also 
primary-referenced. The load module file is opened and the information in the LOCCT 
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is moved into the OPENLM PLIST. In CP-V, if the first word of the EXPIRE field 
is zero, the number of significant words in the EXPIRE control word of the OPEN 
VLP is set to zero. The system library is opened to prevent the alteration of the 
library while the Loader is using it. 

If M:EF was assigned to labeled tape, the M:EF DCB has a 2 in the ASN field. 
All ROMs in the ROM Tables are then assumed to be on the labeled tape and are 
flagged by a 1 in bit position 30 in the third word of each ROM name. Load 
modules added from libraries are recognized as coming from disk, not tape, by not 
having this bit set. 

For BPM, if M:LM has been assigned to a private volume, the (PERM, LIB) bit in 
the LOCCT is checked; the Loader will abort at this point if it is set. 

Finally, the known sizes not associated with CSECTs or DSECTs are added to the TREE. 
These include the TREE size and the TCB size in 01 and 00 of the root. (For BPM, 
an obsolete feature is unfortunately still retained for compatibility - two words at 
the beginning of the root's 01 area are reserved and never used. ) 

The relationship of the LOCCT to the Tree Tables and ROM Tables are shown in 
Figure 14 and the linking among the Tree Tables is shown in Figure 13. 
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LOADER 



MESSAGE 

Read the error 
record from 
ERRMSG and print 




Figure 17. The Loader Driver (in LDR) Flow Chart 
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( ,n ; ti ) 
* 



Obtain Memory. 



I 



Read LOCCT, ROM, and 
TREE tables. 



Initialize stack pointers. 



Set up open list for 
M:LM with param- 
eters from LOCCT. 



Read ASSIGN/MERGE 
record, if any. PREF 
the F: number DCBs. 



PREF MrDOif no 
NOTCB. PREF M.-SEGLD 
if an overlay. 



If M:EF assigned to labeled 
tape, mark every entry in 
ROM table. 



INITSIZE f 



Account for TREE size and 
TCB size in root segment 
tree table. 



QxTj 



Figure 18. INIT1 Flow Chart 
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4.2 PASS! 

We can think of PASS! as consisting of four major parts: the main loop, the object 
module decoder (LP1), the load module processor (ADLDMD), and the librarian 
(SATREF). 

4. 2. 1 The Main Loop 

Starting with the root segment and proceeding along a path, the HEAD record of each 
input file named in the ROM Table for this segment is read and control directed to 
ADLDMD or LP1, depending upon whether the file is keyed or not (ROMs are 
sequential, load modules are keyed). At segment end, SATREF is called to augment 
the ROM Tables by library module names needed to satisfy PREFs (except PREFs to M: 
or F: DCBs). When there are no more forward links, PASS1 writes the current 
segment's stacks on the RAD, updates SEVLEV if there are PREFs (other than M: or F: 
names), and proceeds to the overlay links, then to the back links. See Figure 2 for 
processing sequence. When all of the segments have been processed and their stacks 
written, we will be sitting at the root segment. (Its REF/DEF stack is not written 
since PASS2 needs it immediately anyway). 

At this point, all references to DCBs have been forced to the root. The root's REF/DEF 
stack is scanned for PREF DCBs and they are marked as Type B. FCOUNT contains the 
number of words needed for the DCB Name Table and is also accumulated during the 
DCB scan. In CP-V, REFs to M:XX and M.-UC ("special" DCBs not to be built by the 
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Loader) are satisfied from the corresponding values in the JIT. The entry is changed 
to a library DEF. Figure 3 illustrates the flow of the main loop. 

4. 2. 2 Object Module Processor (LPl-Pass One) 

All names (DEF, PREF, SREF) and control sections are "declared" by the ROM. Reference 
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to these items is by declaration number. This requires that the Loader associate 
a "declaration number" with every name and every control section. 

Inherently, this number is a position in the declaration stack, every entry being a 
pointer to the entry in the REF/DEF stack which contains either the name or the 
protection type and size (if a control section). See Figure 19. 

15 16 31 



Segment's Tree Table 
Displacement 



Displacement to Entry in 
this segment's REF/DEF Stack 



Figure 19. Declaration Stack Format 

LP1 looks at all declarations (control sections and names) and all definitions (DEFs 

and forward references). It ignores all other load items. Every declaration results 

in creating an entry in the REF/DEF stack and an entry in the declaration stack which 

points to it. Every definition results in creating an entry in the expression stack 

whose destination is the REF/DEF stack entry which is being defined. The REF/DEF 

stack may gain one or more entries as a result of a definition whose defining expression 

involves an unknown forward reference. 

a. Declarations - Declarations identify either control sections or names. 

1. Control Sections 

As control sections are encountered, the size is added to the appropriate protection 

type and in the segment's Tree Table for use by INIT2 in allocating buffers. 

Declaration number is special, being dedicated to a standard control section 

(DCSO) for use by one-pass compilers and assemblers. The Loader initially 

generates this declaration for expression reference; the processor will declare 

its size and protection type at the end of the compilation when it finally has this 
information. 



76 



2. Names 

When a name is declared, LP1 makes an entry in the DECL stack. The name 

may have been previously entered in the REF/DEF stack via an object module 

or may now be added to the segment's stack. The appropriate type entry, i.e. 

DEF, PREF, or SREF, is added to the REF/DEF stack if the name is not found. 

In either case, the declaration will point to the segment in whose REF/DEF stack 

the name is stored and will indicate the relative position within that REF/DEF stack. 

A later module may change a PREF or an SREF to a DEF. 

The routine which searches for names and adds them if necessary is ENNAM. 
Incidentally, all names beginning with M:, F: or F4:COM are forced to the root 
segment 's REF/DEF stack. 

NOTE: A dummy section falls into both of the above categories, (See Section 
2. 1. lb. ) Names that have been declared as DEF names may be redeclared as 
dummy sections, with the object language indicating size and protection type. 
Given dummy sections with the same name in different ROMs, LP1 will determine 
the maximum of the section sizes and accumulate it in the appropriate protection 
type and segment in the Tree Tables. 
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Definitions 

Eventually, the ROM will define a DEF or a forward reference. That is, it will 
present an expression in terms of other declaration numbers (other names, control 
sections or forward references) which, when evaluated in the second pass, will 
yield the definition or VALUE (in the REF/DEF entry). For now, the Loader 
simply decodes the expression (in EXPRIN) and builds an entry in the expression 
stack whose DESTINATION is that entry in the REF/DEF stack indicated by the 
declaration number of the DEF or forward reference number. Declarations 
involved in the expression are converted to their REF/DEF pointers (picked up 
from the declaration stack entry) and stared in the appropriate WORD of the 
expression entry. If a Define Forward Reference and Hold expression mentions a 
forward reference number (add FREF), bit 10 of the corresponding REF/DEF entry 
is set for use by SQZ in WRITESEG. 

References to FREF numbers that are not known cause these to be added to the 
REF/DEF stack. These FREFs will later be defined similar to DEFs (see Terminology, 
Section 2. 1 . Id.). 

At module end, the forward reference numbers are released, severity level is ac- 
cumulated, and control returns to the main loop of PASS!. Figure 20 illustrates 
the flow of LP1. 
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Figure 20a. PASS1 Object Module Processor (LP1) Flow Chart 
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EXPRIN 
Purpose: 



Input: 



Output: 



Comment: 



Flow: 



Expression Decoding Routine (in PS1) 

To decode a ROM expression which defines a DEF or forward 
reference and place a corresponding expression in the expression 
stack. 

(R7) = pointer to REF/DEF entry which is to become 
the destination of this expression. 

(D2) = Declaration Stack Base 

(D3) = Tree Table Pointer 

(SR4) = return address 

(SR2) / if expression is to be skipped. 

A new entry in the expression stack consisting of decoded 

expression. 

The destination is from R7, and resolution = 0, 

Expressions are decoded if they follow a Define DEF, Define 
Forward Reference or Define Forward Reference and Hold. 
Hence, this routine is entered for the purpose of decoding only 
from those three points in LP1. All other expressions are skipped 
in PASS1. The expression skip mode is determined by SR2 
(SR2/ 1 means skip.) 

A skeletal entry is appended to the expression stack with resolution 
set to and destination set with R7. 
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| 03030000 


(R7) 


1 00000000 



Top of expression stack. 



An expression control byte is gotten (CBj) and inserted into its 
slot and the appropriate decoding routine is entered. 

The decoding routine gets the item (constant, forward 
reference number, declaration entry, etc) which is to be 
stored in WORD; and branches to PTWRD which puts it in the 
new expression entry. If a forward reference is mentioned in the 
expression (add FREF) and this forward reference is new, it is 
added to the REF/DEF stack. 

When the expression end control byte (02) is encountered, EXPREND1 
updates the expression stack pointer, adds the size of the entry 
to the TREE and exits. 

4. 2. 3 Load Module Processor (ADLDMD - PASS ONE) 

A load module may be encountered as a result of either an EF specification or satisfying 
a PREF from a library. In either case, ADLDMD has at its disposal a header, a TREE, a 
REF/DEF stack, an expression stack, and the core image and relocation dictionary for 
one (and only one) protection type. 

Using the space just above the REF/DEF stack, PASS! reads the TREE record to determine 
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the REF/t)EF stack size. The expression stack is read in just below the current 
expression stack and inverted, since the stack is being built upside down. An addi- 
tional expression stack entry is added preceding the load module's expression stack. 
The additional entry contains a pointer to the special REF/DEF control section entry 
for this library load module. If extended memory mode is entered, this will be used 
in the second pass by the expression stack squeeze logic. All the expressions, with 
the exception of the special expression stack entry, must be marked as unevaluated 
(bit 8 = 0) so that PASS2 logic can recognize the expression as such. 

All core expressions in the load module (e.g., an expression that defines the address 
of an instruction in terms of an unsatisfied reference) have their destinations changed 
to be relative to the base of the load module. These will later (in EVL) have the con- 
trol section base added to yield the correct destination word. 

The REF/t)EF stack is read in below the expression stack. An additional control section 
is added at the start which reflects the size of the entire load module (potentially many 
control sections) (See Section 3.2.3). The other control sections will be type 6 instead 
of type 4 and will hence be ignored by PASS2. The special control section also con- 
tains as the third word (normally, resolution) the relative position (within the expression 
stack being built) and size of the load module's expression stack so that the core ex- 
pressions can be located and evaluated. 

Each entry in the load module's REF/t)EF stack is merged into the large REF/t)EF stack. 
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Control sections are added, and all named entries (PREFs, SREFs, and DEFs) are passed 
through CHKRFDF and are either added or not added according to whether the name had 
previously been encountered. 

Forward REFs are flagged as "used" so that they will be ignored. Dummy sections are 
flagged as "defined". Space willbe allocated forthe entire module; reallocation of any 
individual dummy section within the module is undesirable. 

If the Loader generated the load module (as distinct from PASS2 of SYSGEN which 
also generates load modules), each entry in the REF/t)EF stack has, as its value, the 
header of a chain (through the expression stack) of all words that pointed to that REF/ 
DEF entry. The values are relative positions within the expression stack. 

These values are replaced by the actual location of the REF/bEF entry. If PASS2 of 
SYSGEN generated the load module (indicated by the header, 81 being SYSGEN's 
PASS2 and 82 being the Loader), then each expression must be decoded control byte 
by control byte to find out which words are pointers to the REF/bEF stack. These are 
changed as above. 
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Figure 20b. PASS1 Load Module Processor (ADLDMD) Flow Chart 
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4.2.4 The Librarian (SATREF) 

a. Load Module Libraries 



The satisfy-reference logic works as follows: after each segment's element files 
have been read and its REF/DEF stack built, SATREF is called to satisfy the segment's 
PREF's by searching the specified libraries. Thus we attempt to satisfy all the PREF's 
we can in a lower segment before starting to build the REF/DEF stack for a higher 
segment. 

The purpose of this approach is to handle the situation where a high segment contains 

a PREF which is also contained in a lower segment and the corresponding DEF is in a 

library. It is certainly desirable to have the library routine containing the DEF in the 

lower segment (otherwise the high segment and all of its backward path would have to 

be in core every time the lower segment needs this DEF). Note that this method 

produces the following result: if a low segment has a PREF whose corresponding DEF 

is located in both a higher segment and one of the specified libraries, the library DEF 
will be used. 



SATREF initiates the library search by checking the LOCCT for UNSAT account numbers. 
The first dictionary (:DIC) is opened and the segment's REF/DEF stack is searched for 
the lowest (alphanumerically) PREF. This name is used as the key for reading the 
dictionary. If the response is "no such key, " the alphanumeric search continues through 
the stack for the next lowest PREF. If the read is successful, the record read contains 
the name of the load module with the DEF corresponding to the PREF key, and the 
load module is merged with the other input files in*the manner described below. 
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In either case, the search continues until all of the segment's PREFs have been checked 
against this dictionary. Then the first dictionary is closed and the next dictionary is 
opened. 

Each time a library load module is to be merged with other input files, room is made 
for inserting an entry in the ROM table at the end of the entries for the given segment. 
The last ROM bit is set on the previous entry, and reset on this entry. It is also flagged 
as coming from a library to save unnecessary opens and closes later. (See Figure 8.) 
All other tables are moved up eight words in memory to make room for the insertion 
(the extra word maintains even-word boundaries on the REF/DEF stacks). Pointers from 
the TREE to higher parts of the ROM Table are adjusted up by eight words. 

The name is transferred to the ROM Table and to the open element file PUST. If not 
already open, :UB is opened. The header is read into BUF with the key LMN concat- 
enated with HEAD. Control goes to CHECKROM which verifies the header and calls 
the load module processor ADLDMD to form the appropriate stack entries. The routine 
then returns for the next PREF. 

When there are no more PREFs and no more accounts, control returns to the main loop 
of PASS 1. 

b. Core Libraries (CP-V only) 

The association of core library is triggered by one of two conditions: 

a. A PREF to 9INITIAL (FORTRAN) or 9DBINIT (FORTRAN DEBUG) 

b. The presence of a :Pn in the UNSAT list on the ILOAD card. 

In ENNAM, a record is kept in word CORELIB if 9INITIAL or 9DBINIT is encountered 
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as a PREF. 

In the SATREF loop, CORELIB is checked as is the UNSAT list (for a :Pn). 
If either condition dictates a core library, the :Pn HEAD is read to determine the 
core library's context size. This is retained in CORELIB for future use by ALLOCATE 
in PASS2, which must bump the DATA location counter (DLOC) accordingly. Control 
is transferred to ADLDMD (via CHECKROM) in order to merge the DEFs of :Pn in 
with the REF/DEF stack. 

The association of core library is inhibited if (PERM, LIB) is specified or if the load 
module name begins with the characters :P. This is done by setting CORELIB to -1 
in INI. 
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Figure 21. Core Library Association Flow Chart 
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5. PREPARING TO FORM THE CORE IMAGE 

5. 1 IN2 

INIT2 contains the logic which partitions memory for PASS2 usage. It also determines 
the size of each protection type area for the final load module. First, the size of the 
TCB and library error tables is accounted for, the necessary information being in the 
LOCCT. The DCBName Table size is calculated from FCOUNT which was computed 
at the end of PASS1 (two is added for the top and bottom of the table). 

Then each path of the TREE is followed, and the sums of 00, 01, and 10 segment sizes 
are accumulated in Dl, D2, and D3. When a segment has no sublink, these sums are 
compared with SRI, SR2, and SR3, respectively to determine the maximum path for 
each protection type. Also, the large protection type for a single overlay segment is retained 
in MAX00, 01 and 10. This is done in order to allow for CSEG buffers of the maximum 
size. 

ALLMEM is called once to allocate buffers for the core image and relocation dictionary 
(unless absolute) of the root segment, and again with the values MAX00, 01 and 10 for 
current segment loading. The double buffering permits dummy sections in the root and 
higher segments all to store into the section in the root. The byte addresses of these 
buffers are in RSEG00 through CREL10. The buffers are allocated from the top of memory 
(TOPOMEM), down. 

The load module's location counters are held in DLOC, PLOC, and SLOC (00, 01 
and 10 respectively). They initially represent the beginning of each of the three TREES. 
The bias or background lower limit is used as the beginning value of DLOC, and the 
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Figure 22. INIT2 Flow Chart 
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PLOC and SLOC are computed. These values plus the total sizes of the 00, 01 , and 10 
areas, respectfully, are saved in BUF-BUF+5 for generation of the allocation summary 
by ALLOCATE. 

We now have to allow space for the maximum stack paths. 

In PASS1, the maximum REF/DEF and expression stack size was saved. It is known that 
the REF/DEF stack will not grow and also that the declaration stack is still at its 
maximum size. The expression stack is allocated immediately above the REF/DEF stack, 
and the top of it is compared to the bottom of the buffers. If there is enough room, 
PASS2 begins with memory partitioned as shown in Figure 8; otherwise we determine wherner 
extended memory mode can be entered. If so, the maximums of 

|SEG |SEG( are computed and 

C |REL| %, R|REL|°i 

the buffer pointers for the current segment and the root are set equal. Hence for the con- 
catenation phase of XMEM there will be six (or three) buffers to work with. See Figure 9b. 

5.2 PS2 - THE DRIVER FOR THE SECOND PASS 

PS2 is really a driver for the second pass. It calls ALLL, EVL, and WRT as it proceeds 

along the segments. In addition, for extended memory mode, PS2 calls SQZ for expres- 
sion evaluation and to squeeze the root's expression stack. Figure 5 illustrates the 
overall sequence for this pass. 

5.3 ALLL - MEMORY ALLOCATION 

Refer to Figure 1 for memory layout of the load module being formed. DLOC, PLOC, 

and SLOC — the three location counters for 00, 01, and 10 — have been established 

91 90 18 03C -2(4/75) 



at their beginning values by INIT2. If the segment being allocated is the root segment, 
we save a pointer to the TREE and increment the PLOC location counter by the TREE size. 

We save a pointer to the DCB Table and increment PLOC (or SLOC if CP-V) by the 
DCB Table size. If REF or BREF was specified, we increment PLOC by the number 
specified by the user, or supply the default. 

PLOC now has the location of the first control or dummy section. Control goes to 
LOADFO and LOADM to allocate the F: and M: DCBs (Still only for the root segment). 

For CP-V, if rounding has occurred to prevent DCBs from overlapping page boundaries and 
the adjustment did not fit in the RSEG10 buffer, it must be taken into account at this time 
by readjusting the Loader's buffers for protection type 10 (refer to Figure 8). The additional 
size is accounted for in the root's tree and, if the load module is relocatable, in the 
root's relocation dictionary. Buffers are moved down for the root's and current segment's 
core image buffers and for their corresponding relocation dictionary buffers if the load 
module is relocatable. If in nonextended memory mode the buffer shifts result in a 
collision with the expression stack, the Loader will abort at this point. 

Next all 01 protection type sections are allocated by putting PLOC into the value word, 
setting the resolution, and adding the size to PLOC. Then we go to work on the 00 
protection area, first accounting for Blank COMMON*, then establishing the TCB pointer, 
and then appropriately incrementing DLOC (root segment only). All 00 protection 
type control and dummy sections are then allocated. Finally, using SLOC, all 10 
protection type sections are allocated. 
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A final run is made through the REF/DEF stack to put values in the control sections 
read from the library. Since these are all type 6 entries, they were not allocated; 
therefore, the value of the last type 4 entry is put in the first type 6 entry encountered; 
that section size is added and put in the next type 6 entry, and so on until a new type 
4 entry is encountered. 

If the segment just allocated is the root, the allocation summary is output, including a 
possible adjustment in the 10 size for CP-V as a result of rounding DCBs to prevent 
overlap on a page boundary. 



If CP-V, we first account for the core library's context area, 
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Figure 23. ALLOCATE Flow Chart 
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6. FORMING THE CORE IMAGE (EVL) 

EVL is entered from PS2 once for each segment, beginning with the sublinks, to the 
overlay links, and back down toward the root (see Figure 4). It has two entry points, 
EVEXPRS and LOADSEG. PS2 first calls EVEXPRS (or EVEXSQZ if in extended memory 
mode) to evaluate all expressions for this segment which were formed during the first 
pcss. It then calls LOADSEG to actually form the core image and relocation dictionary 
by reprocessing the object language of a ROM or reading in and relocating the core 
image of a load module. 

6. 1 EVEXPRS 1 

Since all control and dummy sections for a given segment have been allocated at this 

point, we are in a position to evaluate the expressions which are typically in terms of 

these values plus constants. Because some expressions will be in terms of other DEFs, 

every expression in the stack must be evaluated repeatedly until one complete pass 

has been made during which no expressions were evaluated. Evaluating an expression 

consists of decoding the expression's control bytes. (Note that we are "decoding" those 

expressions which are already in the expression stack from the first pass. Since we are not 

forming the stack entry, EVEXPRS is a much simpler version of expression evaluation 

than the EXPRIN routines found in PASS1 and LOADSEG.) 

If tSe byte is either an add or subtract declaration or a forward reference, the corresponding 
entry in the REF/DEF stack is picked up if it is defined. If it is not defined, the expression 
cannot yet be evaluated. The other control bytes add constants or affect the resolution. 
When the expression is successfully defined, the value and resolution are put into the 
REF/DEF entry pointed to by the destination word of the expression. Core expressions 



This routine is identical to the EVEXSQZ routine of segment SQZ. 
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(which come from load module expression stacks in PASS!) are ignored at this point. 
(This routine may also be entered (later) from ADLDMD for the purpose of evaluating 
core expressions which come from load modules.) 

6.2 5QUEEZ 

When the SQUEEZ routine is entered, extended memory mode is in effect and 
EVEXSQZ has just been called by PS2 to evaluate all expressions for the root that were 
formed during the first pass. Those expressions which are not core expressions and have 
been evaluated, and whose values have been stored away for the target DEFs or forward 
references will never again be accessed. SQUEEZ removes them from the root's expres- 
sion stack by building a new expression stack on top of the old one and moving each un- 
evaluated or core expression entry from the old stack to the "top" of the new stack. 

SQUEEZ recognizes a library load module's expression stack by the special entry pre- 
ceding it. The special entry is discarded along with qualifying evaluated expressions. 
After squeezing a library load module's stack, SQUEEZ adjusts the expression size and 
displacement fields of the corresponding special REF/bEF entry preceding that library 
load module's REF/t)EF stack. 

Finally, SQUEEZ adjusts the expression stack pointer doubleword and, in the tree, ad- 
justs the size of the root's expression stack and the starting address of each overlay seg- 
ment's expression stack to reflect the decrease in stack size. 
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6.3 LOADSEG 

LOADSEG can be viewed as consisting of three major parts: the main loop, the object 
module processor (LP1) and the load module processor (ADLDMD). (Notice the similarity 
between LOADSEG and PASS 1. ) 

6. 3. 1 The Main Loop 

The main loop begins by initializing the relocation dictionary buffers if XMEM is not 
in effect. The buffer is filled with E's or O's for the current or root segment, respectively. 
The segment name is printed at top-of-form if a map was requested and a ITREE card was 
present. LOADSEG now begins to reprocess the input files by running through this 
segment's ROM table. Control is directed to LP1 if the module is a ROM or to ADLDMD 
if it is a load module. 

Both LP! and ADLDMD are concerned with developing the core image. The logic of 
extended memory mode (XMEM) will come into play for every word of the core image 
and every relocation digit which is constructed. When information is about to be stored 
into a buffer (core or relocation) and extended memory mode is in effect, a three-byte 
key is created consisting of the segment number and a page number. (For a standard 
load module, this number corresponds to the page address of the buffer this record will 
go into during the concatenation process. For the paged load module, this number cor- 
responds to the page containing this record at execution time.) The key is compared to 
the key of the page currently in memory. (Recall that there are only one or two buffer 
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pages at TOPOMEM.) If the keys are not the same, the page in memory is written out 
and the new key is used to read in the desired page. 
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SEG = Displacement within TREE Table of this segment's entry 
PAGE = Page number of the concatenation buffer. 



Figure 24. Format of the Keys of idX (Extended Memory File 

for Standard Load Module) 



6.3.2 Object Module Processor (LP1-PASS TWO) 

An object module is processed through straightforward decoding of the load items. 
The main loop of LP1 is at LDR1 which contains a jump table to the individual routines. 
A control byte of Module End terminates LP1 and control returns to the main loop of 
LOADSEG (at NEXTROM). The load items fall into two categories: those which 
were handled in Pass One (declarations and definitions) and those which were ignored 
in Pass One (start address, origins and items which result in words or bytes in core). 

Of the first category, LP1 handles declarations and definitions as follows: A declaration 
stack is formed again so that expressions can be related to their REF/DEF components. 
Name declarations are handled by looking up the name in the REF/DEF stack, forming 
a pointer to it and entering the pointer in the declaration stack. 



98 



DECL Stack 



Dynamic 
Core 



Current SEG's Buffers 
(S3) | 



Root Buffers 



\ 



REF/DEF EXPR 
Stack Stack \ 



REC 
DICTS 



Code 



REC 
DICTS 



Code 



I I 

s i S I s 

Ol 1 I 3 



Loader 



S | S I S 
0,1|3 



00 



01 



10 



00 
(Data) 



01 

(Proced.) 



10 

(Static. 

Data) 



00 



01 



10 



00 

(Data) 



01 

(Proced.) 



10 

(Static. 
Data) 



Beginning of 
available space 



Executable Location Layout 



.i ,, .i i, 



Tree Tables 



SO 



SI 



S3 



Locations 
determined < 
by IN1T2 



DLOC 



CREL00- 
CREL01 - 
CREL10- 



RREL00- 
RREL01 " 
RREL10" 







CSEG00 ■ 
CSEG01 - 
CSEG10- 



RSEG00 
RSEG01 - 
RSEG10- 



BLL 



Area 1 



^ \ t 

BIAS X| 00 (Data) 



PLOC 

1 \ 



A Protection Type - > Full Access ■ Protection Type = > N 



ROOT 



Area 2_ 

01 (Procedure) 



SLOC 

l Area 3 

1 ! 

10 (Static. Data) 



Jo Write 



ROOT 



Protection Type = > Read Only 



ROOT 



TOPOMEM 



Conditions: 1. BPM. 

2. Nonextended Memory Mode. 

3. CSEG = S3 (see Figure 2). 



Figure 25. Snapshot of Core Usage During EVL 
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Control sections are handled by looking through the REF/DEF stack for the first TYPE 4 
entry. The type is then changed to a 6 to prevent its being used again, the pointer is 
formed and entered into the declaration stack. Expressions which define DEFs and for- 
ward references are skipped. Define forward marks the FREF entry in the REF/DEF stack 
with an FO and FF (depending on Define Forward Reference or Define Forward Reference 
and Hold, respectively). Forwards with FO are marked with FF at module end to prevent 
their being used again. 

We now consider load items of the second category, and these are, of course, the heart 
of LP1. 

Define Start is handled by evaluating the expression (EXPRIN), shifting the obtained 
value to word resolution and storing it in START (for later placement in the HEAD record). 

LP1 switches from one control or dummy section to another by an origin. The ORIGIN 
control byte (from the ROM) is the only means by which the Loader determines where 
data is to be placed within a control section. (Note: It is the responsibility of the ROM to 
present at least one ORIGIN control byte for every control or dummy section.) The expression 
defining the origin is evaluated (it must be evaluatable and have resolution) and the value 
obtained is shifted to byte resolution. The value is then compared with the bounds of three 
protection types of the current segment and of the root segment. It must be within one of 
those segments. Once the appropriate segment and type are discovered, the base of that 
section is subtracted and the base of the corresponding buffer is added, yielding the 
appropriate byte address at which to place the next load item. This value is put into the 
location counter, LOC. The segment base and buffer base are remembered in BIAS and 
FBIAS, respectfully, for possible use by XMEM. 
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Basically, LP1 is concerned with load items that result in words or bytes in core (that is, 

from a Loader perspective, they result in words being placed in the segment buffers 

or the XMEM file). These items are Load Absolute, Field, Load Long Relocatable, and 

Load Short Relocatable (see Sigma Object language). These items are either 

absolute or contain expressions involving the base of a control section, a forward reference 

or some combination of externals. The expression evaluator, EXPRIN, is used to decode 

and evaluate the expressions. Unless the load module has unsatisfied references, values 

are obtained and the load item is placed in the core image buffer. The relocation digit 

is calculated and placed in the relocation buffer. 

If there is an unsatisfied reference where an instruction references external data, the 
absolute part of the instruction is put in the core image and a "core expression" is 
added to the expression stack. 

Core expressions left in the expression stack in this manner are, in general, meaningful 
when the load module being formed is to become part of the library. In this case, the 
core expression would be evaluatable when the load module is combined with other 
ROMs since the PREFs would presumably have been satisfied. ADLDMD (which would be 
handling the module) would do the evaluating and would insert the value into the field 
part of the absolute instruction in the core image. 

a. Load Absolute 

The simplest item is Load Absolute. This load item contains a byte count followed 
by the number of bytes that are to be placed sequentially into the core image, 
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beginning at the current value of the location counter. The relocation digit for 
these absolute load items is X'E'. 



b. Field 



The field allows an expression to be evaluated and added to any width and any 
position in a word or words. Since this logic handles all relocatable items, it 
includes the development of the relocation digit. 

Before the expression is read, the relocation digit is initialized. If the field 

terminates at the end of a word, the relocation digit will be 0, 1, 2, or 3, 

according to whether resolution is byte, halfword, word, or doubleword. If the 

field does not terminate at the end of a word, left-half doubleword resolution 

or both-hal^es doubleword resolution is checked for. If none of these criteria are 
met, then the item is absolute. 

Next a core expression destination word is constructed (See Section 3. 2.4). 
The expression is evaluated (EXPRIN) and, if it is not absolute, the relocation 
digit is calculated. If it is not evaluatable, FIELD exits. (At this point, a 
core expression has been added to the expression stack; a stack overflow may 
have been encountered if there was no room for the expression.) 

For expressions that have resolution, the relocation digit is the resolution control 
(0 for byte, 1 for halfword, etc.), if the field is right-adjusted. Resolution 
control is the output from WHATRES in R2. In the case of doubleword resolutions 
in halfwords, the resolution digit already present is checked for the case where both 
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halves must be relocated. 

Next, the destination word is used to add the value of the expression to the 
appropriate field in the core image. Remember that this field may extend 
backward across as many as 8 words. 

Finally, if reference loading has been specified (REF or BREF), the CAL and 
PLIST must be constructed. During the expression evaluation, the highest 
segment above the current segment referenced in the expression was remembered 
in RFLDSG (0 means that no REF - loading is required). A pointer to the next 
available location for building the PLIST is kept in the last word of the root 
segment of the TREE Table. The PLIST is constructed in SRI through SR4 with 
the call formed in SR3, and exchanged with the word in memory requiring REF- 
loading. The PLIST is put away in the area saved in the 01 root segment and 
the field logic finally exits. 

c. Load Long/Short Relocatable 

Both of these load items contain a four-byte word and a declaration or FREF number 
to be added to the word ot a given resolution. (Short form assumes word resolution 
and a six-bit declaration number.) For these forms, a byte string that looks like 
a ROM field expression is created in BUF2. (See Define Field in Object Language, 
BPM Reference Manual.) It has the form: 
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BUF 2 
7 



K 



expression 

—A 



15 



23 



31 



15 



23 





FF 




width 


add 


number 


02 



where: 
FF 



w 



idth 



add 



determines the location of the field. 
Rightmost bit is location minus 1 bit. 

is 19 bits less specified resolution: bit for byte; 1 bit for 
ha If word; 2 bits for word; 3 bits for doubleword. 

is 20 bits for add declaration, 24 bits for add constant at 
the appropriate resolution. 



number is the two-byte forward reference or the two-byte 

declaration number if there are over 100 1Z declc 

lo 

or the one-byte declaration number followed by an 00 
02 is expression end. 



(padding) if there are fewer than 101.. declarations. 

16 



The four absolute bytes are then placed in memory at the bcation pointed to 
by the location counter that is incremented to the next word. (The location 
counter must begin at a word boundary or we have an ILLEGAL BOUND.) 
Certain pointers are then switched so that the field logic will get the expression 
from BUF2 rather than from the standard input buffer (BUF) and the FIELD logic is 
called. 

Figure 26 illustrates the general flow of LP1. Two important subroutines of LP1 
are EXPRIN and FIELD, illustrated in Figures 27a, 27b, and 27c. 
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LP1 Routines 



DDNAM 



DPNAM 



DSNAM 



ORG (Origin) 



DFREFH 
or 

DFREF 
DDSECT 
DCSO, DCS 



(Declare DEF name) - Locate the name (LOCRFDF) and declare 
it (ENDECL). 

(Declare REF name) - Locate the name (LOCRFDF) and declare 
it (ENDECL). 

(Declare SREF name)- Locate the name (LOCRFDF) and declare 
it (ENDECL). 

Evaluate the expression which follows (EXPRIN). Shift to byte 
resolution and store value in RLOC. Determine which segment and 
protection type the ORG value is in, then compute the Loader's 
location counter, LOC (=ORG value - SEG base + buffer address •) 

Define forward - Locate entry in stack and mark it with FO and FF. 
Skip defining expression. 



Declaration & is fetched and DSECT declared. 

Locate nexf control section in stack. Change type from 4 to 6 and 
declare. 



DSTART 

MODEND 
FIELD 



LABS 

LSREL 

LLREL 



Evaluate the expression which follows EXPRIN. Shift value to word 
resolution and save in START. 

Update severity level, release all forward REF numbers, exit LP1. 

Form the destination word stack. Evaluate the expression which 
follows (EXPRIN). If a value is obtained, calculate reloc. digit, 
store in buffer and store value in buffer. If no value, leave 
expression stack and exit. 

Fetch bytes and place in buffer. 

Create a field type expression BUF2. Store the four-byte item in 

buffer. 

Call FIELD to evaluate the expression and store in buffers. 
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C L °" ) 

Get load item type. 




1$ it declare DEF, delcare REF, 



^declare SREF, delcare OEF, , 
^define forward, define control ' 
lection, define dummy section ? 



Miscellaneous simple func- 
tions (see description). 



Origin? 



Define 

start? v^yes 



Field? 



'yes 



Load short 
< or long >— 

relocatable? 




( Exit LP1 J 



EXPRIN 



EXPRIN 



r FIELD 
(calls 
EXPRIN) 



Translate value into a 
buffer location counter 
(IOC). 



Save value for later 
placement in HEAD 
record. 



Get the bytes and store 
in loading buffer. 



Place the 4-byte item 
which follows in the 
loading buffer. 



FIELDFB 



Create a field-type 
expression in BUF2. 



Set control byte pointer 
to BUF2. 



FIELD 
(calls 
EXPRIN) 



Reset control byte 
pointers to their 
normal position (BUF). 



c 



LDR1 



D 



Figure 26. PASS2 Object Module Processor Flow Chart 
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FIELD C ENTRY J 



RELFLD2N t 

Form cor* destination 
word far the expression 
which ii about to ba 
evaluated. 




..Absolute v— 
load module T V* 




Adjust relocation digit. 



PUTDIGIT ' 



Put relocation digit in 
relocation buffer. 



STOREFLDN 



Adjust value per desired 
resolution and set into 
proper core buffer. 




Can the item 

j-< stored induce> 

an overlay? 



\£ 



Create entry in REF 
load table. 



X 



FIELDEX 

Did we enter 

<from load >y 

relocatable? 



FIELDFB1 



Reset the control 
byte pointers. 



C EXIT *SR4 J 



£ S 



Figure 27a. Field and Expression Logic Flow Chart 
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EXPRIN 



f Enter J 



Initialize a new expres- 
sion at top of expression 
stack. 



EXPRIN1 



Get a CB. . 



X 



Add declar- 
ation or add\ 

X forward? ^^ 



c 



Error 




< 



Does the expres- 

sion have a value ^^ 

(SR3=0)? 



yes 




* I* *h'* o core v 



no expression ? 




yes 



Adjust destination to be 
relative to module base. 



Retain expression in 
stack. (Modify stack 
pointer and augment 
size in tree. ) 



Register Output; SRI = value (SRI is expression 

accumulator). 



SR2 = resolution. 
SR3 



^ if no value obtained, 
= if value obtained. 



GETVAL 



Get value (if any), add 
to expression accumula- 
tor (see Figure 27c). 



Add it to expression 
accumulator. 



PTWRD 



Save constant or 
declaration in WORD, 
of new expression. 



Determine current 
resolution and shift to 
desired one. 



C 



EXPRIN1 



3 



Pick up resolution 
-SR2. 



f Return J 



Figure 27b. EXPRIN Flow Chart 
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no 




Save the highest segment 
involved in RFLDSG. 




GETVAL4 



Pick up value. 



no resolution 




GETVAL3 



Shift value to resolu- 
tion desired and change 
accordingly in ex- 
pression stack. 



GETVAL2 



Accumulate the value 
(in SRI). 



r~ 

C PTWRD J 



Figure 27c. GETVAL Flow Chart 



SR#0. The 
expression cannot 
be evaluated. 



C PTWRD J 
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6. 3. 3 Load Module Processor (ADLDMD - PASS TWO) 

When a load module is encountered, ADLDMD is called. The special control section 
inserted in PASS1 in the REF/DEF stack containing the address and size of the module 
is located. The buffer address for the core image in the appropriate Loader buffer is 
calculated (in extended memory mode, the image is read in above the expression stack). 
Next, the relocation dictionary is read into its buffer if the mode is not ABS or extended 
memory. In ABS mode, the relocation dictionary is read in above the expression stack. 
In the extended memory (XMEM) mode, it is read in above the core image which is then 
relocated by interpreting each relocation digit and adding the appropriate bias to the 
corresponding word. Next, if we are in XMEM mode, each word of the relocated 
Image is stored through the XMEM logic and the same is done for the relocation dictionary 
if the module is not ABS. 

Since we know the relative beginning and size of the module's expression stack from the 
special control section, we can now evaluate the core expressions in the module's stack 
and resolve any words whose addresses were in terms of PREFs that are now satisfied by 
other modules. The evaluation is performed in the EVEXPR5 section of EVL. The 
relocation digit for each word must also be corrected. The value and relocation digit 
for the core expression is then stored (through XMEM logic, if necessary). 



no 



C ADLDMD J 



Find dummy control section 
for this module. 



Calculate relocation bias 
MBIAS=CSEC value-module 
bias (in HEAD). 



Calculate address within 
buffer for the module's core 
image MODBAS=Buffer 
+(CSEC value-segment base). 



If XMEM, address is 
changed to above expres- 
sion stack (if there is room). 




Read relocation dictionary 
above core image. 



Read relocation dictionary 
into its buffer. 



RELOCATE 
Relocate the 
^core image per 
MBIAS. 



no 




XMEM 



Move each word of core 
image and relocation dic- 
tionary into XMEM buffers. 



ADXM3X 



Get the bounds of the 
module's expression stack. 



»——»-■» 



Begin core expression scan, 



I 



C CQREXP.} 
page 107 



Figure 28. PASS2 Load Module Processor Flow Chart 
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from page 106 




As this a core, 
^"expression? 'no 




yes 



Evaluate it through the 
EVEXPRS logic, 




< 



Is the load v 

module ABS?^yes 




no 



Adjust relocation digit 
and store in rel. die. 
(XMEM if necessary). 



COREXPO 



E 



STOREFLDN 
Store value in 
core buffer (XMEM 
Jf necessary). 



Get next one. 




'Any more v 
y es "expressions? 




CORE XP2 

(Exit ADLDMD\ 
to main loop of \ 
LOADSEG. J 

Figure 28." PASS2 Load Module Processor Flow Chart (cont.) 
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7.0 WRITING THE LOAD MODULE (WRT) 

WRT is entered at WRITESEG from PS2. If this is a library load module, it updates the 
library dictionary (WRITELIB), makes a copy of the REF/DEF stack for mapping purposes 
(LIBCPY), and eliminates forward references from the just copied stack (SQZ routine). The 
segment's stacks are written (WSEGL) as are the segment's core images and relocation 
dictionaries (WSEG1). 

WRT performs several additional tasks after the root has been constructed. If extended 
memory mode is in effect and a standard load module is to be constructed, the pages of 
all of the segments are put together and written out (XMEM). If a paged load module 
is to be constructed, the first record of each overlay segment's 00, 01, and 10 areas are 
shortened and the first few records of the root are read into core to insert the appropriate 
tables (SUPMEM). In any case, once the root has been processed, the DCB Name Table 
is built (SAVEROOT) as well as the DCBs and TCB(FIXROOT). The HEAD and TREE 
records are constructed and written to the load module file. 

See Figure 29 for an overall view of the flow of WRT. 
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c 



■) 




WRITELIB 

Update and write 

library 

dictionary. 



WSEGL % 



Write REF/DEF 
and EXPR stacks 
for tli is segment 



*f TREE ) 




Build DCBs 
and TCB. 



c 



^ 



Write core 
Images and 
relocation 
dictionaries. 




Move copy 
of REF/DEF 
stack above 
EXPR stack. 



SQZ 



/Chain REF/DEFs\ 
\and eliminate 
k FREFs in 
i copied stack/ 



( WSEGL J 




Position to be- 
ginning of file 
and begin read- 
ing sequentially 
(put together 
one segment) • 



SAVEHOOT 



Build DCB 
Name Table 



Read a page into 
the buffer it 
would have gone 
into if non- 
extended memory. 



end of file 
* I 



Insert tables 
in root via 
FIXROOT. 



CWSEG1 A 
and exit J 



Do we have all 
NO /the pages for 

^ this segment (cob- 
^\pare newkey with 

one previously 

read)?/ 

YES 



Shorten first 
records of 
overlay to start 
at execution 
bias. 




C TREE j 



J 



CP-V 




J 



Write out TREE. 
Concatenate key 
if library. 




Build and write 
HEAD. Concate- 
nate key if 
library. 




( EXIT ) 



c 



J> 



Figure 29. WRITESEG -Overall Flow 
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LIBCPY: The MAP routine in FIN must have an unchained, expendable copy of the 

library load module's REF/DEF stack. For this reason LIBCPY makes a 
copy of the REF/DEF stack above the expression stack before the SQZ 
routine is entered. In order to provide as much room as possible for this 
copy, the library load module's core image and relocation dictionary 
records are written out immediately prior to entering LIBCPY. 

After LIBCPY has moved the REF/DEF stack above the expression stack, 

memory layout is as follows: 

TO POM EM 



LOADER 


LOCCT 

ROM 

TREE 


DECL 
Stack 


Original 

REF/DEF 
Stack 


Expr. 
Stack 


Copy of 
REF/DEF 
Stack 





A TREE pointer is adjusted so that the new copy of the REF/DEF stack is 
squeezed, chained, and written out by WRITESEG, and the original REF/ 
DEF stack is used by the MAP routine (which needs the area above the 
REF/DEF stack for sorting names). The start of the original REF/DEF stack 
is remembered in MBIAS. 



SQZ: 



Entry is made to LIBCPY from the WSEG1 routine. After calling SQZ, 
LIBCPY exits to WSEGL, whereupon the proper stacks are written out. 

This routine streamlines a library load module's REF/DEF stack in order to 
expedite subsequent adding of a library to a user's load module. Two 
functions are performed: 

a. at RFDFLOOP —all evaluated forward reference entries in the REF/DEF 
stack with bit 10, word reset are removed from the stack. All 



This routine is not to be confused with the Loader's SQZ segment. 
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evaluated expressions are removed which involve that entry. If 
bit 10 is set, the FREF entry is retained (so that an unevaluated 
DFREFH expression in the library load module involving this FREF 
(add FREF) can be evaluated when it is merged into another program) 

b. At SQZDN -chaining is installed. The VALUE word of every REF/ 
DEF entry becomes the head of a chain within the expression stack 
which replaces pointers to the REF/DEF entry; the tail of the 
chain = 0. That is, the VALUE word of each REF/DEF entry is re- 
placed by a pointer to the word in the expression stack that formerly 
pointed to that REF/DEF entry. (The pointer is a displacement 
relative to the base of the expression stack.) This expression stack 
word is replaced by a pointer to the next user of the REF/DEF entry. 
This process continues until a zero terminates the chain. 

For example, consider a DEF entry which has a displacement of X'B' 
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words into the root's REF/DEF stack. Then any expression involving 
the DEF refers to it by means of a pointer of the form X'B'. Assume 
there are three such pointers in the root's expression stack: PT1, 
PT2, and PT3, with displacements X'F', X'lA', and X'22', respectively, 
relative to the base of the expression stack. Then the chaining process 
with respect to this DEF entry is outlined as follows: 







Contents Before 


Contents After 


Word 


Displacement 


Chaining 




Chaining 


Value of 


X'B' (Into R/D stk) 


Constant or 


Addr 


X'F' 


DEF entry 










PT 1 


X'F' (into expr. stk) 


X'B' 




X'lA' 


PT 2 


X'lA' (into expr. stk) 


X'B' 




X'22' 


PT 3 


X'22' (into expr. stk) 


X'B' 








The benefit is that the expressions do not have to be relocated (with 
respect to the new REF/DEF stack) each time the library load module 
is added to another. 

WRITELIB: Writes the dictionary for the library. This entails three cases. 

The three cases are distinguished via abnormal or nomal returns. In 

any case, a ROM of the same name as the LMN is deleted to insure 

proper handling. 

Case 1 - The library (:LIB and :DIC) do not exist. Here we create them 
by opening in the OUT mode. 

Case 2- The library exists but this new load module is not within it. 
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Case 3 - The library exists and this new load module is to replace 
one with the same name which already exists within it. 

In general, WRITELIB does the following: 

Step 1. Opens the :DIC file; and then it opens the library fife 

with the load module name synonymous to : LIB. The only 
anticipated abnormal return would be that the file : LIB 
does not exist (Case 1) and we go to FIRSTLIB. The file 
: LIB is created and the opening is reattempted with the load 
module name, and we proceed to Step 3. 

Step 2. (RDRFDF) If :LIB already existed, an attempt is made to read 
the REF/DEF stack from : LIB for a module with the same name 
as our module. An error return implies that the desired load 
module is not within : LIB and we proceed to Step 3. If the 
read is successful, a delete CAL is made to the :DIC file, 
with each DEF serving as a key to remove the old module's 
dictionary entries. (A delete CAL is also made for 
each DDEF and DSECT entry in the old REF/DEF stack). 

Step 3. (WRITEDEF) Then, we run through our module's REF/DEF 
stack. Every DEF, DDEF, and DSECT of our module is 
used as a key to write the :DIC file, the record being the 
module name. The dictionary is closed and we exit to 
WSEGLofWRITESEG. 
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WRITELIB 

Open :DIC in 
INOUT mode. 



{Dictionary doesn' t | 
abnormal, exist. Reopen withl 



return MODE - OUT 



Set up open PLIST to M:LM 
for INOUT mode 
File name = LMN 

Synonym = :LIB 



a 



abngrmal^ 
return 



FIRSTUB 



y I he tile exisrs. 

» file with nnmp = i 



Delete the file wirh name 
.MN, to avoid confusion if 
ROM name = LMN. 



irn 



This m<*dule 
doesn't! exist 
within #he library 



N 



Open the M:LM INOUT 
filename = LMN 
Synonym = :LIB 



RDRFDF 



I 



Error Read the REF / DEF Stack for 

frr .pr ^- -| f n ,* s module above the 



1 



buffers. 
EX T DbF 



Run through the REF/DEF 
stack just read and delete 
the corresponding record in 



-W gITEPEF~ *T 

Run through this module's 
REF/DEF stack, writing the 
corresponding record in :DIC. 



Llljrory dpes< 
with mode » 

= :LIB. 



isf., Reopen 
, file name 



Reopen with mode = INOUT. 
File name = LMN, Synonym ~ 




Figure 30. WRITELIB Flow Chart 
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SAVEROOT constructs the DCB Name Table and its relocation 

dictionary. Entries are put in this table for every DSECT 
with a name beginning with M: or F: in the REF/DEF 
stack. The DCB Name Table is initially built above 
the REF/DEF stack (beginning at the expression stack). 
Because the DCB Name Table was the only item requiring 
the REF/DEF stack after mapping the stack can now be 
destroyed and we move the DCB Nbme Table down to the 
declaration stack (at TAMOV). This is done to make as 
much room as possible for the reconstruction of XMEM 
files, if necessary. (If there is no room to build the 
table, i.e., we would collide with the buffers, loading 
is aborted). 



Initially: 



or 



EXPRBAS 



XMEM BUFFERS 



/ 



\ 



Dec I. 
Stack 



REF/DEF 
Stack 



Build DCB Name fable and 
its relocation dictionary 



CSEG 
Buffers 



Root 
Buffers 



X 



after TAMOV: 



DECLBAS 



TOPOMEM 



S 



DCB isbme Table and 
its relocation dictionary 



CSEG 
Buffers 



Root i 
Buffer- ' 



Recall that at the end of PASS1, all PREF DCBs were set to 
type B. During the building of the DCB Name Table, SAVE- 
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ROOT flags the location word (bit 8) of 

each table entry which resulted from a type B REF/DEF 

entry, as a signal for DCB building in FIXROOT . 

FIXROOT: Moves the TREE into the 01 buffer. Then it moves the 

DCB Name Table and its relocation digits to the buffers 
(01 for BPM, 10 for CP-V). The TCB and its relocation 
dictionary are built in the 00 buffers. The DCB Nime 
Table is scanned for those DCBs which are to be built by 
the Loader. If one is to be built (we know this from the 
hi -order flag bit in the location word of the entry), 
FIXROOT builds it (in 01 for BPM or 10 for CP-V) then 
checks whether it has a standard name. If so, default 
information is inserted. The proper relocation dictionary 
is built. In BPM, if the load module is being 
written to private disk pack, the serial number (s) 
is inserted in the M:SEGLD DCB. 



XMEM: 
(BPM only) 



This routine is entered only if CSEG =root segment and 
extended memory mode is in effect, and a standard load 
module is being constructed. Its function is to recon- 
struct the load module from the XMEM file into the form 
necessary for writing it out as a keyed file in load module 
format. This requires that the pages be placed in the 
core image and relocation buffers, (see Figure 9b). Re- 
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call that the keys of idX indicate the page number of 
the buffers (see Figure 24). 

The last core buffer is forced out and, if the module is not 
ABS, the last relocation dictionary buffer is forced out. 
The file is positioned to its beginning and is read sequentially, 
first with byte count to get the next key from which the 
buffer address is calculated and again to read the page in. 
This process continues until an end-of-file is encountered 
or the segment number in the key changes. If the segment 
read is the root segment, FIXROOT is called. The segment 
is then written out into the normal load module file. This 
process continues until all segments are reconstructed. 
Notice that the advantage afforded to large load modules 
by XMEM during this concatenation process is that the area 
of core otherwise dedicated to the stack can now be part of 
the 6 buffers. 

A final constraint on the size of the load module that can be 
concatenated is that the DCB Name Table and its relocation 
dictionary (which have been temporarily placed at DECLBAS 
and up by SAVEROOT) are co-resident with the largest 
segment. 
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SUPMEM: If extended memory mode is in effect and a paged load module is being con- 
structed, SUPMEM is entered immediately, after the current segment's stacks 
are written. If the segment is not the root, return is made to ENDWRT1 where- 
upon WRITESEG exits. If CSEG is the root, the following functions are performed. 

The last core image record (from EVL) is written out and SAVEROOT is called 
to build the DCB Name Table. Upon returning from SAVEROOT, the size of 
the root's tables are determined and, in the order of protection types, GETRECS 
is called to read in the records which are to contain these tables (if the records 
already exist). 

GETRECS reads in the first such record into the first available page above the 
DCB Name Table. The next record is read just above this page, and so on. If 
GETRECS tries to read a record which does not exist, it still reserves space for 
this record in the next available page. Finally, the buffer pointer corresponding 
to the protection type of the records being read in (RSEGOO, RSEG01, or RSEG10) 
is adjusted to point to the beginning of these records as they sit in core. 

After these records have been collected, FIXROOT is called to build and insert 
the table. The updated records are then written out. 

Next the first record of the 00, 01, and 10 areas of each overlay segment if it- 
does not begin on a page boundary (and the root's 00 area, if it is a core 
library, has been associated) must be shortened to start at the first word of 
code. This is done by reading each record into the page at the top of memory 
(as a 512-word record). The size of the record to be output is computed from 
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the execution bias in the segment's TREE. The buffer pointer is moved accordingly 
and the truncated record is written out. 
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When this process is complete, SUPMEM exits and the HEAD and TREE records 
are constructed. 

8.0 FINISHING UP (FIN) 

The FIN segment comprises the final stage of the Loader. By now the entire load module 
has been written out. All that remains is to output the severity level, perform any mod- 
ifications per IMODIFY cards, and generate the load map. 

FIN is entered from LDR at FINISH. FINISH computes and outputs the severity level. 
At this point the user sees the general allocation summary and the severity level. Next 
the MOD routine is called. This routine establishes the environment for both the MODIFY 
(Catalog Number 705396) and MAPER routines. If the severity level is less than or equal 
to the maximum (supplied by the user or CCI in the LOCCT), modifications are performed 
per the IMODIFY cards which have been packaged into the idD file by CCI. In any case 
MOD calls MAPER to generate the load map. 

MOD first checks to see if: 1) a library load module is being formed; 2) extended memory 
mode is in effect; or 3) the severity level is greater than the allowable maximum. If any 
of these conditions are true, a flag (N01DD) is set to inhibit modifications. Otherwise 
the idD file is opened (if the file doesn't exist, N01DD is set). The REF/DEF stack for 
the first segment is read (except for a library load module, whose stack is already in core). 

Now if N01DD / 0, this segment is mapped and the next segment's REF/DEF stack is read. 
If N01DD = 0, the core images and relocation dictionaries for this segment are read, the 
idD file is read, the MODIFY routine is called to perform the modifications, the segment 
is rewritten, and the load map is generated by MAPER. This processing continues until 
there are no segments, whereupon MOD exits to the main FINISH program. 
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At this point, if the severity level is greater than the maximum allowable, the loader 
aborts. Otherwise FIN closes M:LM and M:LL (load module and map DCBs) with SAVE 
and returns normally to the driver in LDR (which exits to CCI or PASS3). 

See Figure 31 for a flow of the FIN segment. 

MAPER: The MAPER routine works mostly within the framework of the REF/DEF stack 
itself in order to generate a segment's load map. The routine does, however, 
use the core above the REF/DEF stack for two purposes: 1) to save "displaced" 
DEF entries (a DEF whose defining expression is located in another segment) so 
they can be included in the map of the segment in which they are defined; 
2) to collect sort keys (a pointer to a REF/DEF entry) of all the names of a 
particular type (e.g., SREF, DEF, PREF) in order to produce an alphanumerically 
sorted name list. The displaced DEF stack is saved throughout the entire load 
module mapping process and is constructed from TOPOMEM down. The sort keys 
are destroyed after each name list is written (the keys are built just above the 
REF/DEF stack). Any possible collision between these areas results in halting 
the addition of more sort keys/displaced DEF entries. See Figure 32 for mem- 
ory layout during MAPER. 

MAPER first outputs several lines of preliminary information which it obtains 
from this segment's TREE (and the LOCCT table, if this is the root segment). 
The boundaries and sizes of the protection type areas are computed by the 
SEGEVAL routine and translated and output by VALMOVE. Then four major 
routines - PREPROC, PSMALIST, SORTMAP, and MAPLIST -are called in 
succession to generate the name lists. 
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PREPROC runs through the REF/DEF stack, deleting unnecessary REF/DEF 
entries (FREFs and control sections with zero size), clearing the resolution word 
of each entry (used for chaining the stack in SORTMAP), flagging ADEFs, and 
resolving relocatable values to word resolution with a byte displacement (of the 
form X'OBOAAAAA'). In addition, each displaced DEF entry in this stack is 
moved to the displaced DEF stack and deleted from this stack. After the entire 
REF/DEF stack has been scanned, the displaced DEF stack is examined for any 
entries belonging to this segment. If any are found, they are appended to this 
segment's REF/DEF stack. 

MAPER calls PSMALIST four times —each time to generate a list of a specific 
type of REF/DEF entry. In this way PSMALIST produces the PREF, SREF, DDEF, 
and ADEF lists (no list is generated if the stack is void of that type of entry). 
PSMALIST scans the REF/DEF stack for a given type of entry, building sort keys 
for all the entries of this type it finds. Then SSSUBR is called (via SRTEXIT2) 
to perform the sort and MAPFIN3 is called to list the names. 

SORTMAP uses the resolution words to chain (in order of ascending value) 
either: I) all CSECTS, DSECTS, and relocatable DEFs if (MAP, VALUE) was 
specified on the LOAD card, or 2) all CSECTs, the first relocatable DEF in 
each CSECT, and all DSECTs if (MAP, NAME) was specified. Also, if NAME 
was specified, SORTMAP builds the sort keys for the relocatable DEFs in the 
sort area and calls SSSUBR to sort them. 

MAPLIST directs the generation of the relocatable DEF list. After the correct 
heading is printed, the chain through the REF/DEF stack is followed to move each 
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entry to the output buffer. Whenever MAPLIST encounters a control section 
as the next link, it calls NUSECT to write out the current line and move the 
control section's information to the buffer. If the NAME option was specified, 
MAPFIN3 must be called to sort and output the DEF names. 

Note : The sort routine implemented is that described in a "A High-Speed 
Sorting Procedure", D.L. Shell, Communications of the ACM, Vol. II, 
July, 1959. 
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APPENDIX A 



LOADER-GENERATED INTERNAL SYMBOL TABLES (CP-V ONLY) 



PURPOSE: 
DEFINITIONS: 



USAGE: 



COMMENTS: 



INPUT: 



To output internal symbol table (1ST) records as a part of a load module. 

A source program can contain both internal and external symbols. An 
external (or global) symbol is one which is declared as a DEF in this 
program and which may be referenced in other, separately assembled 
programs as a REF or SREF . An internal symbol is one which applies only 
within the given source program (and hence is not REF 'd or DEF'd). A 
symbol table consists of a list of correspondences between symbols used 
in a source program and the values or virtual core addresses assigned to 
them by the Overlay Loader (or LINK). 

The association of internal and external symbol tables with a user's pro- 
gram enables the user to reference such symbols under various debugging 
processors (in particular, under DELTA). Under DELTA, the user can 
operate on his programs in what appears to be assembly language sym- 
bolic; with regard to internal symbol tables, he has the ability to define 
which set of internal symbols are to be used for specific debugging 
activities. 

The Loader builds internal symbol tables only. (Global symbol tables 
can be generated by the SYMCOM processor.) Each 1ST corresponds to 
one particular ROM. If more than one ROM is contained in an element 
file, an 1ST is generated for only the last ROM in the file. 1ST genera- 
tion is suppressed for library load modules and core libraries (i.e., load 
modules whose name begins with :P). 

The Loader generates an internal symbol table entry when it encounters 
a "Type and EBCDIC for Internal Symbol" load item (control byte X'12') 
in a ROM. See BPM Reference Manual, Appendix A, for the format of 
this load item . 
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OUTPUT: 



The loader outputs one 1ST record for each element file (specified in 
the EF list) which contains a ROM with 1ST load items. The record is 
a keyed record, the key consisting of the element file name concatenated 
with X'10\ The internal symbol table has two types of entries -symbols 
whose values are constants and symbols whose values are addresses. 



1 2 



SYMBOL TABLE FORMAT -ADDRESS TYPE 



78 



45 7 



12 13 



31 



1 


CT 


SYMBOL IN TEXT 






TYPE 


RES 


VALUE 



31 



where 

CT = Character count of the original symbol. 

SYMBOL = The first 7 characters of the symbol . Symbols with fewer 
than 7 characters are zero-filled. Longer symbols are 
truncated to 7 characters, though the original character 
count is retained. 

TYPE 



RES 



00000 


Instruction 


00001 


Integer 


00010 


Short floating point 


00011 


Long floating point 


00110 


Hexadecimal (or packed decimal) 


00111 


EBCDIC text (or unpacked decimal) 


01000 


Logical array 


01001 


Integer array 


01010 


Short floating point array 


01011 


Long floating complex array 


10000 


Undefined symbol 


is a 3-bit field indicating the internal resoluti 


000 


Byte 


001 


Halfword 


010 


Word 


011 


Doubleword 
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VALUE is the address corresponding to this symbol, in byte 
resolution. 

SYMBOL TABLE FORMAT -CONSTANT TYPE 



1 2 


7 8 


31 


1 


CT 










SYMBOL IN TEXT 


VALUE 



where 

CT and SYMBOL are the same as above. 
VALUE is the 32-bit constant value. 

FLOW: INIT1 checks to see if the (PERM, LIB) option is specified or if the 

LMN name starts with :P. Either of these conditions results in setting 
SYMBOLTB to -1. 

Initialization of the 1ST buffer (to be used for 1ST generation during 
PASS2) occurs in INIT2. Space is allotted for the buffer between the 
expression stack and the core image/relocation buffers. Refer to 
Figures 8 and 9a for the Loader's memory layout during PASS2. (The 
table is constructed from the top end of the buffer down.) 

Internal symbol tables are constructed in the LPT section of LOADSEG. 
When a X' 12' control byte is encountered at LDR1, a branch is made to 
SD12. If SYMBOLTB is non-negative, LPT checks the 1ST buffer limits 
to determine if the expression stack has grown into the 1ST being constructed 
(by the addition of core expressions) or if the addition of a new 1ST entry 
would cause a collision with the expression stack. If either of these events 
occur, 1ST generation is suppressed (SYMBOLTB is set to -1). Otherwise, 
the new entry is constructed and added to the 1ST, and SYMBOLTB is 
updated to point to the base of the new entry. 
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At module end the current 1ST is written out. If this is the largest 1ST 
output so far, its base address (in SYMBOLTB) is remembered in BSEG2 
In any case SYMBOLTB is reinitialized to the first word above the 1ST 
buffer (kept in SYMTOP). 

In WRITESEG, the size of the largest 1ST is stored in Word 8 of the 
HEAD record (as well as its future location under DELTA). 
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SUMMARY OF LOADER RESTRICTIONS 



1. Load Module Size 



The primary constraint with regard to the largest standard load module that can be con- 
structed by the Loader concerns the number (Background size - Loader size file buffers 
LOCCT, ROM and TREE Tables. ) This represents the maximum size of that area 
which must contain the DCB Name Table and its relocation dictionary plus the 
largest core image of each protection type (00, 01, and 10) of any segment and 
their respective relocation dictionaries. 

Background — 





LOCCT 


DCB Name 


00 


01 


10 


00 


01 


10 


1 


Loader 


ROM 


Table and its 


rel die 


rel die 


rel die 


core 


core 


core 


file J 




TREE 


rel. die. 








imago image 


image 


buffers 



VOPOMEM 
largest for any segment 

An additional constraint for a standard load module - and the main constraint for a 

paged load module — is that there must be enough room (in Pass Two) to accommodate 

the Loader, the LOCCT, ROM, and Tree Tables, the maximum declaration, REF/DEF a 

expression stacks, plus 2 pages for building the load module (or 1 page if the module is 

be ABS.) 

2. The name of an input file must be < 10 characters (see ROM Tables). 

3. The name of a load module must be < 11 characters (see LOCCT Table). 

4. If a DEF in a library load module is > 1 1 characters, the corresponding entry in the 
:DIC file is forced to 11 characters. (The DEF entry in the library load module 
itself is not changed. ) 

5. A load module acceptable for the combination with ROMs to form a new load module 
must be of one protection type, relocatable, and not overlaid. DSECTs in such a 
load module are allowed only if the entire load module consists of one DSECT. 
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6. A load module will be set ABS if any of the following conditions exist: 

a) It contains a relocatable field not ending on a half word boundary. 

b) It contains an expression of mixed resolution. 

c) REF or BREF has been specified on the 1LOAD card. 

7. Segments may communicate with each other via REFs and DEFs only if they lie 
in the same path. 

8. Load items of a DSECT are always placed in the corresponding DSECT of the root 
segment. That is to say, there must be a DSECT by the same name in the root. 
The following case is not permitted. 



A DSECT 
RES 3 



Root 



A DSECT 
DATA 1,2, 3, 



9. The loader cannot perform modifications (! MODIFY) on a library load module. 
That is, a I MODIFY following a ILOAD (PERM, LIB) will be ignored. 

10. The loader will ignore modifications (IMODIFY) if extended memory mode has 
been entered. 

11. If a low segment references a DEF name which is both in a higher segment and a 
library, the library DEF will be used. 

12. No two segments on the TREE control command may begin with the same ROM 
name, since the first ROM named in a segment becomes the name of that segment. 

13. For BPM, a library load module may not be constructed on private disk pack. 
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14. If a low segment common to two or more paths references a DEF name that is in 
a higher segment of more than one path, that name will be doubly defined. 
The following case is not permitted: 



DEF A 



REF A 



Root 



DEF A 



15. A program containing a relative address preceded by a minus sign (e.g. , 
-BA(addr)) is not relocatable. 

16. If extended memory mode is entered for CP-V, the load module being built 
must have no more than 256 segments. 
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COMMON QUESTIONS ABOUT THE LOADER 

1. Why is the expression stack retained as a permanent part of the load module? 
The expression stack is retained far only one reason: that is, for the purpose of 
combining the load module with other ROMs. At the time of combination, we 
must process the unevaluated core expressions to complete the load items which 
involve PREFs. The PREFs will presumably have been satisfied and the expressions 
involving them will not be evaluatable. 

2. What are the final contents of the expression stack? 
The final contents consist of: 

a. Defining expressions for DEFs and forward references. (If this is a library 
load module, only those expressions involving unsatisfied forwards are 
retained. The others are squeezed out as are the REF/DEF entries which 
identified the forward numbers.) 

b. All unevaluated core expressions (core expressions are unevaluatable if they 
involve PREFs). 

3. Load modules which are combinable with ROMs can have only one protection type. 
Why is this so? 

Generally speaking, load modules are relocated by computing a relocation factor 

(=new bias-module bias). This relocation factor is added to all relocatable items 

in the module. (The relocation factor is actually modified via the relocation digit 

to the proper resolution but this is irrelevant for the current discussion.) 

Consider a load module with two protection types. 

If we try to combine this load module with other ROMs we must also relocate the 
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core images (00 and 01) with respect to their newly acquired position in the 
target load module. Having detached the 00 and 01 areas we have of course 
changed the relative distance from one to another and now cannot compute a 
relocation factor since "module bias" is meaningless. 

Example: Consider a load module, X, with two protection types 00 and 01. 

The instructions at a are in 01 and ZAP is in 00. 

a LW, 1 ZAP 

LI,1 $ 

Assume that in X, 00 begins at relative location and 01 begins at relative 

location 500. Assume that ZAP is relative location 100 and a is relative 550. 

Now assume that for the new module, X', the new positions for 00 and 01 are to 
begin at 2000 and 4000, respectively. 

The Loader sees only the core image from X: 

(4050) LW, 1 100 

(4051) LI, 1 551 

It has no way knowing that it should relocate for X' by adding 2000 to a but 3500 to 
a+ 1. 
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APPENDIX B 



STORAGE LAYOUT OF STUFF 



NAME 



DISPLACEMENT 



CONTENTS 



DECLSTK 

DECLSTK1 

RFDFSTK 

RFDFSTK1 

EXPRSTK 

EXPRSTK1 

DECLBAS 

RFDFBAS 

EXPRBAS 

BSEG1 

BSEG2 
CSEG1 

CSEG2 
CROM1 
CROM2 



+0 
+1 
+2 

+3 

+4 
+5 

t° 
+7 

+8 

+9 

+10 
+11 

+12 
+13 
+14 



CRFDF1 


+15 


CRFDF2 


+16 


CURBYTE 


+17 



RECDSIZE 



+18 



Declaration stack pointer doubleword. 

Declaration stack pointer doubleword. 

REF/DEF stack pointer doubleword. 

REF/DEF stack pointer doubleword. 

Expression stack pointer doubleword. 

Expression stack pointer doubleword. 

Base of declaration stack; see Figure 9b. 

Base of REF/DEF stack. 

Base of expression stack. 

Temporary segment number; used for small subroutines 
as in INIT1. 

Base address of largest internal symbol table. 

Displacement from beginning of tree tables to be- 
ginning of tree for current segment. 

Temporary storage for renumbering current segment 
number; used in PS1 for temporary sequence number 
in the name routines. 

Current ROM pointer in ROM table; displacement 
from start of ROM table to current ROM; used in 
PS1 and EVL. 

Temporary storage for current ROM pointer; used in 
PS1. 

Pointer to the current REF/DEF entry being looked at. 

Top of REF/DEF stack being looked at. 

Displacement into card image now being read in 
GBYTE; contains last byte read in ROM record. 

Size of ROM record just read by GBYTE. 
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NAME 



DISPLACEMENT 



CONTENTS 



SEQNUM 

SEVLEV 

XSL 

LASTCARD 
BUF 



+19 

+20 

+21 

+22 
+23 



BUF2 


+53 


TEMPPTR 


+57 


TREEPTR 


+58 


RELPAGE 


+59 


FCOUNT 


+60 


FTABLE 


+61 


ERRTAB 


+62 


ERRSTK 


+63 


TCBSIZE 


+64 


I TCBPTR 


+65 


FTAB 
| 


+66 


RSEG00 


+67 


RSEG01 


+68 


RSEG10 


+69 



Actual sequence number of record just read in GBYTE 
routine. 

Severity ievel of load module; starts out with that of 
ROMs; gets raised if need be; see WRT and FIN. 

Maximum severity level from ILOAD card; now in 
LOCCT. 

Flag that this is last card of this ROM; see GBYTE. 

Used in PS1 and EVL as input buffer for reading ROMs; 
used as output buffer by FIN; used as buffer for the 
map; some of its words are used by WRT. 

Used to construct an expression from load relocatable 
type load item; see pages 98 and 99; used in WRT. 

Used to keep track of temp stack in user's TCB; see 
INIT2, ALLL, WRT. 

Pointer (execution type address) to loader —built tree 
table; used in WRT. 

Library page number to be released; used 
in PS1. 

Size of DCB name table; used in PS1. 

Starting address of DCB name table at execution time. 

ERTABLE size from the LOCCT. 

ERSTACK size from the LOCCT. 

Total size of target TCB including ERSTACK and 
ERTABLE sizes; see WRT and IN2. 

Execution starting address of target TCB; see ALLL 
and WRT. 

Starting address of DCB name table at execution time; 
set in ALLL; used in WRT. 

Pointer to root segment for protection type 00; see 
Figure 8. 

Pointer to root segment for protection type 01; see 
Figure 8. 

Pointer to root segment for protection type 10; see 
Figure 8. 



90 18 03C -2(4/75) 
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NAME 



DISPLACEMENT 



CONTENTS 



RRELOO , 

RREL01 

RREL10 

CSEGOO 

CSEGOl 

CSEG10 

CRELOO 

CREL01 

CREL10 

MAXOO 

MAXOl 

MAXIO 

DLOC 

PLOC 

SLOC 

LOC 

START 

LOCCT 

LOADBAS 



+70 

+71 

+72 

+73 

+74 

+75 

+76 

+77 

+78 

+79 

+80 

+81 

+82 
+83 
+84 
+85 
+86 
+67 

+88 



Pointer to root segment's relocation dictionary for 
protection type 00; see Figure 8. 

Pointer to root segment's relocation dictionary for 
protection type 01; see Figure 8. 

Pointer to root segment's relocation dictionary for 
protection type 10; see Figure 8. 

Pointer to current segment for protection type 00; 
see Figure 8. 

Pointer to current segment for protection type 01; 
see Figure 8. 

Pointer to current segment for protection type 10; 
see Figure 8. 

Pointer to current segment's relocation dictionary for 
protection type 00; see Figure 8. 

Pointer to current segment's relocation dictionary for 
protection type 01; see Figure 8. 

Pointer to current segment's relocation dictionary for 
protection type 10; see Figure 8. 

Largest protection type areas which have to be allo- 
cated for each segment; see INIT2, FINDLGSTPATH. 

Largest protection type areas which have to be allo- 
cated for each segment; see INIT2, FINDLGSTPATH. 

Largest protection type areas which have to be allo- 
cated for each segment; see INIT2, FINDLGSTPATH. 

Execution location counter for 00. 

Execution location counter for 01. 

Execution location counter for 10. 

Load location counter; see EVL. 

Starting address; gets put in HEAD; see DSTART in EVL. 

Address of LOCCT, first available page above loader's 
procedure. 

Actual load bias; either from LOCCT or defaults to 
BGLL; see INIT2. 
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NAME 



DISPLACEMENT 



CONTENTS 



MODBAS 

RELDBAS 

MBIAS 
FBIAS 



PUB 

LIB 
XMKEY 

LOCWD 
USID 



+89 

+90 

+91 
+92 



BIAS 


+93 


RDIG 


+94 


MODSIZ 


+95 


NOTLLM 


+96 


MAXRFDF 


+97 


MAXEXPR 


+98 


TOPOMEM 


+99 


OPENEF 


+100 


OPENDIC 


+117 


PBUF 


+132 


CSECFLG 


+153 



+154 

+155 
+156 

+ 157 
+158 



Used for merging core image record into XMEM buffers; 
see EVL. 

Base of relocation dictionary for core image library; 
used in EVL. 

In WRT, start of original REF/DEF stack. 

Used for paged load modules; address pointing into 
loader's core image buffers; see ORG in EVL; see 
also WRT's old XMEM code. 

Equivalent of ORG *o execution address of start of ROM. 

Relocation digit; see ADLDMD. 

ARS from M:EF after .erding relocation dictionary; 
see ADLDMD in EVL. 

Flag in WRT for not a library load module. 

Computed dynamically in PS1 to find longest REF/DEF 
path needed by PS2. 

Computed dynamically in PS1 to find longest expres- 
sion path needed by PS2. 

Last available address (ends in E). 

Contains the open PLIST for M:EF. 

Contains the open PLIST for :DIC. 

Print buffer for loader diagnostics. 

Flag for special CSECT used in merging library Imns; 
see ADLDMD in PS1. 

Flag which gets set if addition of a core expression 
would cause expression stack to overwrite a core image 
buffer above it; see EXPRIN routine in EVL. 

1 if a library Imn is being added; see ADLDMD. 

Extended memory mode key used to write core image 
records; initialized in INIT2; used in EVL and WRT. 

First word of the LOCCT, containing parameter bits. 

User ID number passed in register by Monitor; used in 
INI and IN2 to open temporary file. 
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NAME 



DISPLACEMENT 



CONTENTS 



RFLDSG 



+159 



ERFLAG 


+160 


MXRFDFSG 


+161 


NXTAVPG 


+162 


RLOC 


+163 


OlSIZ 


+164 


TRESIZ 


+165 


FCOMSIZ 


+166 



XMRKEY 


+167 


04LOC 


+168 


DOREFPTR 


+169 


RFLDTBSZ 


+170 


BREFERR 


+171 


PASS3RET 


+172 


ENTFLAG 


+173 


CORELIB 


+174 



See REF/BREF option; segment number of where DEF is 
defined in the branch referencing mode. 

Message key; see MESSAGE. 

Contains segment number; aid in determining path 
having largest REF/DEF stack; see PS1. 

Execution address of page just above the load module; 
gets put in HEAD; computed in INI; picked up in WRT. 

Loader's load location counter for relocation dic- 
tionaries; goes with LOC. 

For special CSECT in merging library Imns; see ALLL. 

Size of the loader to see if it must do SEGLOADs or 
can just branch; see LDR. 

Size of blank COMMON from the LOCCT; set up in 
PS1 when loader finds ROM defining F4COM; takes 
largest size for any DSECT declaration with name or 
F4COM. 

Extended memory mode key for reading the relocation 
dictionary. 

In ALL pointer to remember last control section when 
searching for special library control sections; in 
SPECDSEC location of an 04 entry. 

In BREF mode pointer to name S:OVRLY in REF/DEF 
stack; see INI. 

REF count from LOCCT, word 4, 

Count of REF's overflowing table; if in BREF mode, 
count of nonbranching REF's overflowing table; BREF 
error in EVL is picked up in FIN„ 

Information saved for PASS3/CCI if must return to it; 
see INIT1 and LDR. 

Type of entry we are making: PASS3 or CCI; see 
INIT1 and LDR. 

CP-V only; used in PS1 to show whether REF to 
9DBINIT or 9INITIAL set; see INIT2 and WRT; also 
used to turn off trigger. 
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NAME 



DISPLACEMENT CONTENTS 



BFR 



+175 



Pointer into BUT; storage for checksum in 
GBYT.E; also in FIELDEX routine of EVL used 
in switching logic for define field. 



FIRSTF 



+ 176 



Pointer into REF t)EF stack for first forward 
reference. 



LASTF 



+177 



Pointer into REF/DEF stack for last forward 
reference. 



XCSEG1 



+178 



See XMEM logic of EVL; retains current segment 
to permit alternate use of CSEG1 for XMEM. 



SYMBOLTB 



+179 



Base of current internal symbol table. 



SYMTOP 



+180 



Top of current internal symbol table. 



TRAPCC 



+181 



For CP-V; retains condition codes when loader 
enters its trap handler for trap 40; see LDR. 



CODE 



+182 



New field of information output with diagnostics; 
part of QUIT procedure. 



KICKOUT 



CFUPTR 



+183 



+ 184 



Used in expression stack squeeze logic; in 
ADLDMD in PS 1 , used to save pointer to li- 
brary Imn's special REF/DEF entry; inSQUEEZ, 
contains count of entries deleted from root's 
expression stack. 

For CP-V; pointer to value word of M:* REF/DEF 
entry; see INI and IN2. 
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